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Omega language features two major components: a set of 
production rules executed through pattern-directed invoca- 
tion, anda relational database of values and objects. We 
develop a simple system of rule evaluation which relies on 
hashed indexing for rule selection and a list implementation 
of relations. The system's ferformance is evaluated in 
comparison with LISP and Prolog interpreters. We conclude 
with a discussion of our experience in developing example 
applications, and recommend extensions te the language kased 


on this experience. 
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A. BACKGROUND 


Two major issues in programming language design can be 
characterized as abstraction and architecture. in ties 
context, abstraction refers to the ability of the language 
to capture the ideas of the programmer. It 1S a@ measure of 
expresSiveness or semantic power. Architecture refers to 
those language characteristics, both organizational and 
Syntactic, that affect practical usage. This includes ease 
of use for the programmer as well as the potential for effi- 
cient implementation. Thus an important goal for a progran- 
Ming language is to combine a fowerful abstraction ability 
with an effective language architecture. 

Conventional languages have suffered in both of these 
areas. These languages focus on the use of assignment 
statements for computation, and execution consists of the 
sequential flow of program control between assignment state- 
Ments. John Backus described these "von Neumann" languages 
as excessively complex and _ weak, wnose word-at-a-time 
conceptual basis has created an "intellectual bottieneck" 
{Ref. 1: pe 615]. These languages are oriented more towards 
the word-at-a-time stored program computer than towards the 
problem domains they attempt tc satisfy. Thus they have 
POOE daDSClIaGtiloOn ably. While simple, elegant imperative 
languages such as Pascai have enjoyed popularity, the need 
for increased power has resulted in complex languages such 
as Ada. Such languages have attained semantic power at the 
expense of architectural effectiveness. 

Several alternatives to the von Neumann languages have 


been developed. Of interest in this thesis are applicative 


eZ 


languages, object-oriented languages, and rule-rased infer- 


ence lanyuages. 


B. APPLICATIVE LANGUAGES 


Applicative languages use the application of a function 
to its arguments as the focus for computation. These 
languages are typified by pure LiSP [Ref. 2], and by iater 
functional languages such as FP [Ref. 1] and KRC [Ref. 3]. 

The strengths of the applicative languages are exenpli- 
fied by arithmetic expressions. These strengths include 
clear interfaces between computational units, relative inde- 
pendence of evaluation order, and a semantic regularity that 
lends itself to simple verification and proof technigques. 

Functionals, functions which receive functions as argu- 
ments and return functions as results, provide a méechanhisa 
for the combination of simple, frimitive computational units 
into collections of arbitrary pcwer and compiexity. 

The applicative languages achieve their predictability 
Baegely {from the prohibition of side-effects during computa- 
te OT) This caaracteristic limits the problem domains to 
which applicative sclutions can be readily applied. Like 
the arithmetic expression, applicative languages cannot 
readily describe the notion of state. There is no explicit 
notion of time in an arithmetic expression, and applicative 
languages are correspondingly weak in maintaining temporal 
relationships. Tisomeenaractersti1c limats the utility of 
applicative languages in inherently state-oriented appiica- 
tions. Such applications include operating system activi- 


ties, data base management, and discrete simulation. 


C. OBJECT-ORIENTED LANGUAGES 


The object-oriented languages have developed from sinu- 


dation languayes such as Simula [Ref. 4], and are typified 
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by Smalltalk {Reis =5]s Smalitalk partitions the progran- 
mer's model into collections of objects called classes. 
Objects have a state associated with them, and the metanods 
(procedural information) of the ciass determine an object's 
computational behavior. Both data and procedural informa- 
tion are organized around the object. 


The object-oriented approach aliows certain important 


Capa Dilit res: Foremost, the concept of state iS (ieee 
ingrained in the language. The simulation approach facili= 
tates the modeling cf real-world activities, with concil. 


rency readily handled througa the mechanism of communicating 
objects. 

Associated with the class mechanism in Smalltalk is the 
concept of inheritance. When a new object is created, it 
obtains certain default state and behavioral characteristics 
from its class. In the functicnal languages, combinatorial 
power is obtained through subordinate function application 
and the use of EU eeroOnats . In the object-oriented 
approach, combinatorial power is obtained through composi- 
tion of new objects from existing ones, and through 
inheritance. 


D. INFERENCE SYSTEMS AND LOGIC PROGRANMING 


Inference systems have developed through artificial 
intelligence efforts at cognitive modeliny, knowledge repre- 
sentation, and theorem proving. Based on the early produc- 
tion system of Post [{Ref. 6], these systems use rules, 
Similar to logical implication, that provide the Compiuias 
tional framework for a program. Rule-based organization has 
been described by Newell [Ref. 7], and an early language 
based on the concept was Hewitt's PLANNER [ Ref. 8]. 
Numerous rule-based systems have since been developed, with 


notable examples being theorem ;rovers such as AM [Ref. 9], 


14 


and expert systems such as MYCIN [Refs 10}, DENDRAL 
[Ref. 11], and PROSPECTOR [ Ref. 12}. 

Prolog iS a general-purpose language which uses’ rule- 
based theoren proving as the computational metaphor 
[Rei. 13]. Distinct from the applicative languages, Prolog 
uses pattern-matching instead of the procedure call to 
determine the applicability cf rules and the resulting 


computations. 


E. A COMBINED APPROACH 


The preceding discussion highlights the following 


features offered by these languages: 


e Function application provides a powerful, regular mecha- 


nisn for stateless computation. 


e An object-oriented approach provides an effective crgan- 
ization for data and procedures which is useful in 
representing temporal relationships) and real-world 


okjects. 


e Rule-based pattern-matching systems have provided an 
alternative way for expressing complex knowledge 


representation. 


The Omega language [{Ref. 14) represents an approach that 


combines these features into a single language framework. 


Fo. AN IMPLEMENTATION STUDY 


The emphasis of this thesis is on the implementation of 
an interpreter for the Omega language. As an implementation 
study, the focus is on language architecture--tnose charac- 
teristics of the ianguage that were conducive or that 
presented obstacles to efficient implementation. Of partic- 


meagre interest in this effort are the characteristics o£ 


i 


interpreter organization, data representation, Yanda co menem 
strategies used in the implementation, and how these charac- 
teristics impact on the performance of the systen. 

This work 1S a fErototyping “ettomm Because of the 
experimental nature of the language, various extensions and 
modifications were required on preliminary designs. To 
support this experimentation, two prototypes for the inter- 
preter were written. The first was a throw-away prototype 
WELLtTCD in “Pranz oe. The second was a more complete, 


incremental development written in C. 


G. A SUBJECTIVE EVALUATION 


As a secondary emphasis, some attention is given in this 
work to the evaluation of Cmega aS a general-purpose 
programming language. While these observations are largely 
subjective, they provide some insight into the implementa- 
tion probiems associated with these early prototypes. 
Having prototype interpreters up and running has also 
provided an opportunity for experimentation with Omega 
programming that may frove useful in the early evaluation of 


features in the language. 
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Ii. AN INFORMAL DESCRIPTION OF THE LANGUAGE 


A. GENERAL 


This chapter provides a descriptive summary of the 
features of the Omega languaye. The descriptions are mainly 
by example, and serve to provide a feel for the language 
constructs, not detail. 

The material in this chapter is based on the work of 
MacLennan. The philosophy, informal and formal semantics, 
and original syntax of the jlanguage are introduced in 
[Ref. 14}. Some syntactic and semantic differences exist 
between the original description of the language given in 
fRef. 14] and the prototype implementations. Later chapters 
will deal with the rationale for these deviations. The 
implementation syntax is used in this chapter to maintain 
consistency with with the remainder of this thesis. A 
description of the implementation syntax is contained in 


Appendix A. 


Be. OBJECTS AND VALUES 


The entities of the system are divided into values and 
objects. The values of the system include numerics (inte- 
gers and reals), character strings, and lists. Lists are 


denoted Ey square brackets, such as: 
rela", pues Ue 2 ie 


Objects are referenced by name,’ and are subject to the 


following properties: 
e Objects are unigue. 


e Objects nay be shared. 
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e Objects are subject to change over time. 
e Objects may be created and destroyed. 


The distinction between objects and values is discussed in 
[Ref. 15]. Subsequent examples should help to illustrate 


the rcle of objects in Omega. 


C. A RELATIONAL MODEL 


The components of the language are organized according 
to a relational nodel. The mcdel iS consistent with rela- 
tionai terminology introduced by Coda [Ref. 16]. 

Consider an object that represents a gueued process 
Waiting for an operating system resource. For reference 
purposes, the object must Efe naned, so call Ttiae 
Associated with the object are a priority, P, and a tape 
drive allocation requirement, T. The priority and resource 


reguirements are values that must be associated with the 


JOD These associations may be described by a Priority 
relation and a TapeDrive relaticn. This could be expressed 
as Priority(J, P), TapeDrives(J, T). In these expressions, 


the pairs <J, P> and <J, T> are called tuples. 

A tuple is an ordered collection of objects and values. 
Note that, unlike relational database models, named attri- 
butes are not used to descrite a tuple. Instead, the 
members of a tuple are described by relative position (order 
1S important), by value, and by pattern—maccieee 

A relation is a set of tuples. Relations are described 
by name, and through pattern-matching. As a set, the tupies 
of a relation are (1) uwunicue and (2) unordered. 

Objects serve as representative place holders in rela- 
tions. The state of an object is determined by the rela- 
tious ain which it  pawrveneates? and by the attributes 


associated with the cpject in these relations. 
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Relations themselves are cbjects, although they are 
distinguished by having an intrinsic value: the collection 
of tuples instantiating the relation. AS objects, relations 


may be members of tuples and participate in other relations. 


D. PATTERN-DIRECTED FRODUCTION RULES 


The relations organize the primitives of the systen. 
Thus, at a given time, the state of the system is character- 
ized by its relations and the entities bound through these 
reiations. To complete the model, a mechanism must be used 
to describe state transitions. Pattern-directed production 
rules are used for this purpose. 

A rule is a pair <a, c>, where a is termed an antecedent 
and ca consequent. An antecedent consists of Boolean 
conditions that pertain to the state of the systen. The 
conseguent consists of actions that will be executed if the 


conditions of the antecedent are true. Rules are written: 
if <antecedent> -> <conseguvent>. 


A condition may be one cf several constructs. The most 
fundamental is the inguiry. An inguiry is a pattern-matched 
test described by the rule that is performed against tne 
relaticus of the systen. AS anexample, consider the job 
gueue again. A rule may be desired that checks for jobs 


requesting 4 tape drives. This could be expressed as: 
if TapeDrives(j, 4) -> ... 


where the conseguent of the abcve rule is not shown. The 
expression TapeDrives(j, 4) iS an inguiry, and may be read 
as "if there 1s a tuple <entity, 4> in the TapeDrives rela- 
tion, then return true and bind the entity to the variable 
j-" The symbol j in this example 1S an unbound logical 


variable, which is considered a wild card in an attempt to 
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match the inguiry against the tuples of the relation. Once 
a logical variabie has become bcund through an inquiry, this 
binding will remain in effect for that particular eee 

The following, more complex, inquiry relies on variable 


Dead De \ 
if TapeDrives(j, n), Priority(), >) = eee 


The comma is considered as a lcgical "and" between the two 
inguiries. Thus, the antecedent of this rule will be evalu- 
ated as true if tuples exist in the TapeDrives and Priority 
relations such that the first mwember of each tuple is the 
same. This corresponds to the equality join of relational 
database systens. 

It is important to note that inguiries are existentially 
quantified. An inguiry is evaluated as "if there exists a 
tuple <x1, «ee, XN> ib relation RR, vetburnyteue 

It is also important to note that the logical variable 
binding done during fpattern-matching is in effect only for 
the duration of “the puve. The scope of a logical variable, 
then, is the rule where the variable occurs. 

Other variables may have more permanent bindings, and 
behave like constants. There 1S no syntactic distineried 
between free and bound variables. To avoid contusion 
examples, free logical variables will aiways begin witha 
lower case letter, bound variakles and constants will begin 
in upper case. 

Another type of antecedent condition is a test for the 


absence of a tuple. This condition has the forn 
if aTapedDrives{ 3, 4). eee 


which is read "if it 1s not the case that a tuple <3pyeeGe 
exists in the TapeDrives relaticn." If the tuple fattern is 
not a member ort the relation, the expression is evaluated as 


true. 
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The absence of a tuple from a relation might or night 
not be interpreted as the negation of its presence. If one 
uses a "closed world" assumption, then absence is the same 
as negation. The logical interpretation of an absence test 
is dependent on the programmer's intent and assumptions. 

Free variables are not bound in an absence test. 


Consider again the rule: 
if ~TapeDrives(j, 4) -> ... 


For the antecedent to be true, there is no tuple <j, 4 in 
the TapeDrives relation. Therefore, the free variable j 
will remain unbound. 

The inguiry and absence conditions form the basis for 
the evaluation of the current state of the system. An addi- 
tional mechanism is provided for the evaluation of state 
information. This mechanism is termed a constraint, and can 
be any Boolean expression. 

Consider the case where one is interested in determining 
if a job reguires more than 5 tape drives. Thi Seeder be 


expressed as : 
mmlapebrives{}], 0D); mo > 5 => « < « 


where the expression n> 5 1s a constraint. The join 


example shown previously could te rewritten as 
meolapemeryves( aw, 2), PELOILty (32,%p), jilej2—-> « . 


The conseguent portions of rules alter the state of the 
systen. The actions of the consequent typically update 
relations in some way. The fundamental actions are asser- 
tions and deletions. 

An assertion adds a tuple toa relation. Consider the 


mule: 


if Request (resource, job), Avail(resource) -> 


Allocate(resource, Ol) 2. 


on 


It the contents of the Reguest and Avail relations match the 
inguiry patterns, the rule will "fire", and add the tug. 
<resource, job> to the Allocate relation. 

In the previous example, the free variables resource and 
job were bound in the antecedent portion of the rule. These 
bindings were maintained through the consequent portion of 
the rule and determined the instantiation of objects added 
to the Allocate relation. Free variables, therefore, must 
be bound through pattern-matching before their use in the 
conseguent of a rule. 

The allocation example raises some problems. The ruie 
successfully allocates a resource to a job by the assertion 
to the Allocate relation. This assertion, however, does not 
alter the conditions Request and Avail that initiated the 
Euless liming. Tis, this rule may conceptually "fire 
forever" unless some action is taken to disable one or more 
of its conditions. 

The deletion is used for this purpose. The allocation 


rule may be written as: 


if Request (resource, job), Avail(resource) -> 
-~Request (resource, jotl), 
~Avail (resource), 


Ailocate (resource, jot). 


The deletions ~Regquest(resource, job) and 7Avail (resource) 
remove the indicated tuples from their relations. 

The preceding actions--determine a pattern-match cf a 
tuple within a relation, then remove the tuple--is a typical 
sequence. An abbreviated syntax for this Sequence is the 
cancel operation. Using cancel operations, the preceding 


rule may be written: 


if *kKRecuest (resource, job), *Avail (resource) =~ 


Allocate(resource, jok). 


The cancel operation returns true if the indicated pattern 
is matched against a tuple in arelation. If the antecedent 
or tne rule succeeds (ali conditions are true), then the 
maples matched during cancel operations are deleted ron 
their relations. 

Rules may be coupled through aliternation. In the 
preceding rule, an aiternate action may be desired if the 


requested resource is not available. This is expressed as: 


if *Regquest(resource, job), *Avail(resource) -> 
Allocate (resource, jok) 
else if *Request(resource, job) -> 


Blocked(resource, job). 


The antecedent of the alternate rule will be evaluated if 
the primary rule Zfaiis. In this example, the erfect will be 


foeplace the job in a blocked state. 


E. THE APPLICATIVE COMPONENT 


Function application is used to support the state tran- 
Sitions described above. In those cases where a tuple nust 
be specified, an applicative expression may be used to 


compute the value of a member. Consider the following rule: 


Pesta pemrives{(), ny, bm + i <= 10 -> 


TapeDrives(j, 2 * n). 


This rule uses infix arithmetic operators to compute values 
in a constraint and during an assertion. Such operators are 
permissible in constraint expressions and in the conseguent 
portions of the rule, with the restriction that variables 
participating in such expressions must be bound. In the 
preceding example, the variable n waS bound in the 


TapeDrives inguiry. 


Zo 


Named functions may also be used within expressions in 
the same way as the infix operators. This is shown in the 


following rule: 


if *AvailTapeDrives(1L1), *TapeQueue(L2), 
(17 s= Nil) € (2 == Ni) 
AvailTapeDrives (Restj11}), 
TapeQueue (ReSt{ 12 j), 
Allocate (First[ Li], fiesceeaye 


In this example, available tape drives and jobs queued for 
tape drives are represented as lists. The functions 
Firstjx] and Rest{x]J return the head and tail pointers of 
their argument. 


Functions are declared as fcllows: 


fn facipx ] = she x. <a ee 


else x * fact); x-iyie 


This example illustrates that function bodies are similar to 
rules, and are in fact conditional expressions. The antece- 
dent of a conditional expressicn is a Boolean expression, 
but not an inguiry or absence test. The consequent ofa 
conditional expression is another expression, not an asser- 
tion or deletion. Thus, conditional expressions (and func- 
tion bodies derived from them) are free of side effects. AS 
the factorial example illustrates, runctions may be deciared 


recurSively. Iterative constructs are not defined. 


F. PROCEDURES 


A typical invocation sequence for a rule begins when a 
tuple is added to a relation. The tuple is associated with 
an agent--the object or process that made the assertion--and 
the agent often expects a group of rules to execute asa 
result of this assertion. Finally, the agent may expect a 


value or object to be returned. 
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tol Piistuate tris, consider the @ssertion of a tuple in 
the Request relation. Such a tuple may be <a, r>, where tne 
ebject ais a relation representing the agent, and the 
object r indicates the resource desired. This assertion was 


made to trigger the following rule: 


if *Request(a, r), *Avail(r, id) -> 
a (id). 


In this example, the relation ais used as a mailbox to 
receive a response from the server rule. The assertion oft 
the tuple <a, r> is similar to the creation of a conven- 
tional activation record, and the mailbox a is similar to 
the activation record of the caller. 

The assertion a(id) places the desired response--a 
resource identifier--in the relation belonging to the 
requesting agent. When this response appears in the mailbox 
relation, the -regquesting agent may extract the result and 
continue its computations. The maiibox relation serves aS a 
svnchronization and value-returning mechanisn. 

In an event-driven system, such a calling sequence would 
be a common usage pattern. This is recognized by the inclu- 
sion of a calling mechanism within the language. The above 
sequence could be initiated by a synchronous call. Consider 


the fellowing rule: 


if *InitProc(p), *Regquire({f, cr), ~Allocate(p, x) -> 
Allocate(p, Request {r}). 


The Request expression in this example iS a Synchronous 
procedure call. Its effect is the automation of the mailbox 
handling of the previcus rule. The call Request {r} wiil be 
translated by the system into an assertion Reguest{a, 1). 
The object a is a system-supplied relation that will receive 
a response from rules firing as a result of the assertion. 


When a tuple is added to this relation, the tuple is 


ZS 


returned as the result of the frocedure call in the expres- 
Sion wnere the call was invoked. 

The procedure call as shown in the preceding exampie is 
Similar to the functicn invocation described earlier. Both 
invocations may be used in expressions, returning results 
that are incorporated in expressions. The underlying mecha- 
hisms of the function and procedure call are different, 
however. In particular, the frocedure call relies on the 
use of rules to describe its actions, and therefore relies 
on side effects. 

The server rule in this example may be triggered by 
elther an assertion cr procedure call involving the Request 
Felation. There is nothing abcut the form of the rule that 
indicates its use in procedure calls. By convention, 
however, such rules must use the leftmost member of a tuple 
in the enabling relation as the receiver of the response. 

The value returned by a procedure call does not have to 


be used in an expresSion. In the following example: 


if *Function(job, c), =Codeltable(ec7 de!) 
Display{"Illegal function code"} 


an assertion to the Display relation is assumed to eventu- 
ally cause the message to be displayed at the user's 
terminal. The value returned by the calling mechanism is 


used for synchronization only, and is otherwise ignored. 


Ge. SEQUENTIAL CONTRCL 


In the preceding examples, no particular orden wa. 
assumed for the evaluation of conditions in the antecedent, 
and no order is assuned for the execution of the actions in 
the consequent. These actions may be considered to be 
asynchronous and concurrent. This situation becomes even 


tore unstructured when a collection of rules is being 
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considered for evaluation. Once again, no evaluation order 
is assumed. 

The seguential block provides a mechanism for the 
programmer to specify an explicit order for rule evaluation. 


This is shown in the following: 


if *Reguest (a, Ir), -~Avail(r) -> 
eae sis ilay tT  Haltimo fOr resources... '"} ; 
if *Queue(r, 1) -> 
Queue(r, cons{[a, 1]); 


} 


The effect of this jfruie is to display a message and to add 
the reguesting agent to a queue for the desired resource. 
The seguential piock guarantees that the ruleS within the 
f}'s will be evaluated in the order shown. 

As the example indicates, the variables bound in the 
antecedent retain their bindings in the seguential block. 
The blocks may be nested, with the bindings of free vari- 
ables extending to inner blocks. 

In this example, the antecedent 1S omitted in the 
Display rule. This is eguivalent to a true antecedent. 


When writing such rules, the notation may be shortened to: 
Display {x} 
which is equivalent to: 


Pelee? DiSpiay {x}. 


He. CONTROLLING THE NAME SPACE 


The previous descriptions give a simple mechanism for 
the binding of logical variables. The rules may be summa- 


imezed as: 


Ze) 


e The scope of variables bound in an antecedent extends to 


the consequert for a given rule. 


e If sequential blocks are nested, obpindings made in outer 


Dlocks extend to tmner Dilceks- 


The previous examples have suggested a more global binding 
mechanism, aS indicated in the use of relation names. The 
Request relation name is globaily bound in this manner. The 
mechanism through which global names are managed is the 
directory. 

A directory is a named collection of pairs, <name, defi- 
nition>, where the name entry is a character string and the 
definition is an object or value representation associated 
with the name. The directory may be thought of as a named 
symbol table. 

MacLennan [Ref. 14: ppe 34-35} describes a directory 
structure with two partitions: public and private. Names 
defined in the public partition are globally visible to 
agents other than the owneLr. Names defined in the private 
partition are visible only to the owner. 

A Simple elaboration of this mechanism provides a fiex- 
ible partitioning scheme. The public and private partitions 
are associated with named directories. These Cirectories 
are organized into named classes, not necessarily disjcint. 
In saddii2on- there is a noticn of a "current directory? 
Silllanr tostnae an tix 

The context of a name, then, 1s determined by the 
current directory in which the name is defined. When evalu- 
ating the binding of aname, the current directory public 
and private partitions are searched for an entry. If thie 
local search fails, the public directories associated with 
the classes of the current directory are searched. The 


class structure defines a search path for variapdle lookup. 
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To illustrate these points, Concvder Ene déefkinition of 
the Request relation of previcus examples. Suppose the 
current directory is "ServerDatabpase," a member of the class 


"Servers." The relation is created and named by: 
Define {Private, "Request", Newrel {}}. 


The Define procedure call makes a <name, definition> entry 
into a directory partition. The Newrel {} procedure call is 
assumed to return a unigue system identifier that represents 
aerelation. The definition shcwn, therefore, would create 
the relation and bind a name to that relation in the private 
partition of the current directcry. 

Such a server reiation would be of nore general utility 
than a private definition allows. Before the relation is 
opened to broader access, an access control mechanism is 
necessary. 

This control is achieved by associating capabilities 
with each relation. Wnen a relation is created with the 
Newrel{} procedure cali, full capabilities are associated 
with the relation identifier. These capabilities include 
read, add, and delete. A public definition of the Request 


relation may be accomplished as follows: 
Define{Public, "Request", AddOnly {Request}}. 


The AddOnly procedure cali references the system identifier, 
with full capabilities, that has been bound to the private 
nane Reguest. A copy of this identifier is made with 
reduced capabilities but still referring to the same rela- 
ron . This new identifier is then installed in the public 
directory for general access. THY@S technique Gf capability 
addressing is based on the werk of Dennis and Van Horn 
[Ref. 17}. 


Objects are created in a Similar manner: 


Define{Private, "Jobi", Newobj {}}- 


a 


The Newobj{} procedure returns a unigue identifier to be 
associated with an object. Objects created in this manner 
have no intrinsic value associated with them, and there is 


no access control asscciated with therr 1Tdentiaiye.r 


I. A PROGRAMMING SYSTEM 


The language elements described may be adapted to a 
general programming systen. To simplify interaction with 
the systen, [Ref. 14: ps. 39] suggests the use of rules as a 
command ianguage. 

While syntactically simiiar to production rules, these 
command rules are subject to a slightly different method of 
interpretation. If a user wishes to query the contents of 


the Allocate relation, this may be accomplished by: 
if Allocate (x) => Display ix 


If analyzed as a production rule, however, this query wouid 
be a "fire forever" type. Rules such as this reguire a 
different method of evaluation: test, fire, and forget. 

The command rules represent the second class of rules in 
the system. The first class of rules is that of the produc- 
tion rules previously described. These rules are termed 
active rules. Active rules comprise a body of state tran- 
sition information that continucusly monitors the relations 
referenced in their antecedents. Command rules are initi- 
ated by an event in the system, and only evaluated once. 
The initiating event in previous example was the entry ofa 
command rule at the terminal. 

The active rules are distinct from command rules, yet 
the command rules provide the interactive interface between 
the user and the systen. The two categories are bridged 


with the rule denotarion- 


3.0 


A ruie denotation is a syntactic representation of rules 


as data. A potential active rule may be described: 


Define{Private, "ReguestRules", 
<< 
if *Reguest(a, r), *Avail(r) -> 
Allocate(a, [), a(r) 
>> 
}- 


The denotation is expressed between << >>'S, Which iS inter- 
preted as "parse but don't evaluate." This definition binds 
the parse tree associated with the server rule to the name 
"ReguestRules" in the private directory partition. 

A rule denotation bound in this manner is a data struc- 
ture subject to manipulation by the systen. To make the 
transition from this passive status to active status, the 


rule denotation is activated: 
Activate{ServerRules}. 


At this point, the rules expressed in the denotation are 
moved to active status and enter a continuous’ test-fire 
cycle. 

This process iS similar in many respects to progran 
development ina more conventional systen. The command 
entry of the rule corresponds to the creation of a progran 
source file, and activation corresponds to compilation, 
djinking, and loading. 
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III. DESIGN ISSUES AND GOALS 


A. THE ARCHITECTORE OF RULE-BASED SYSTEMS 


Omega is a production-rule systen. Davis [Ref. 18: p. 


301] describes these systems in terms of three components: 
e A rule base. Omeca'ts set of active rules. 
e A database. The set of relations and their contents. 


* An interpreter. The mechanism for rule selection and 


execution. 


B. RULE SELECTION AND CONFLICT 


The control cycle of the interpreter processes rules in 
a continual recognize/act cycle: The recognition phase 
consists of selection and conflict resoiution { Ref~. 1983.08 
BZ] < 

Omega uses a forward-chaining method for ruie selection. 
This method, described in the examples of the previous 
chapter, compares the antecedent of the rule to the data- 
base. A rule is selected when an appropriate match is 
found. 

In general terms, producticn systems produce a conilict 
set for each recognize/act cycle [Ref. 18; p. 325]. The 
conflict set consists of all active rules whose antecedents 
are true given the current state of the database. in tne 
Omega system, the resoiution of the conflict set is simple. 
For a given cycle, each rule within the conflict set will be 
tested and, if its conditions are true, will fire. The 
order in which the rules in the conflict set are tested is 


not specified. 


BZ 


of 
14: 


The rules 
selected [{ Ref. 


Omega are 


PPe 


19-20}. 


indivisible once they are 


To illustrate this point, 


suppose the following rules were active: 


if *Request (a) 


if *Reguest (a) 


Under this selection strategy, 


fire (assuming there is only 


indivisible nature of rule 


Mutual exclusion for rules such as these. 


tion order for these ruies is 
antecedent wouid have 
priorities. 

The 


powerful execution 


rule selection 
mechanism. 
of the 


and 


procedural information 


state of tne database, 


behavior iS more complex than 


where the thread of execution 


-> Allocate (a, 
-> Allocate(a, 


evaluation guarantees 


to be designed to 


and corrilict 


Red). 
Blue). 


only one of these rules will 


che tuple in Reguest). The 
at least 
Since the evalua- 
not defined, a more explicit 


establish conflict 


strategies Support a 


JS Chis approach, the 
system is sensitive to the 
responds accordingly. This 


a procedure-oriented svsten, 


control is more closely tied 


to the procedural code organization. 


The complexity of rule testing has performance penalties 


associated with the precision of rule selection. 


sion, we refer to the 


humber of 


By preci- 


cules whose antecedent 


conditions are true compared to the number of rules selected 


tor testing. 


precision is 


to Scan the entire 


Pee nost anerractent ana Most Obvious Level.or 


rule base on every cycle. 


We call this a glocal sweep strategy. At the opposite 
extreme is a selection strategy that produces only 
msuccessful" rules for test. 
C. PATTERN-HATCHING 

At the heart of the rule evaluation process is pattern- 
Matching. Given the form of a rule: 


iene ij) —> . 9. 
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date tuple x in R is; 


match[x, el]: 
if x=Nil and e1l=Nil 
return TRUE 
else if x=Nil or e1=Nil 
return FALSE 
else if ei is an aton 
if el is unbound 
bindjel, x] 
history := cons[ ely histonmm 
return TRUE 
else if el = x 
PeEcurn 2Rus 
else 
Let Uri wos 
enda.t 
else 1f match[first[x =, first[{e1]}] 
return match[/ rest; x}, restfetl]] 
else 
EECLUEN FALSE 
endit 


enag match 


This description assumes a LISP-like list representation for 
tuples. 

This pattern-matching process is expensive. 
Incorporating this method at the heart of the interpretation 


cycle presents a significant design challenge. 
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D. KORE CONVENTIONAL ISSUES 


Besides these unusual desigh issues, Omega is subject to 
the same design reguirements as more conventional languages. 


These include: 
e A parser and lexical scanner tor command/rule input. 


e A procedure-oriented evaluation component for applica- 


tive expressions. 


e A flexible symbcl table mechanism for the support of 


directories. 
e Dynamic typing. 


e Dynamic memory ailocation and reclamation. 


E. DESIGN GOALS 


the design goals for the prcectotvpes are grouped into the 
areas of feature implementation, relation representations, 


efficiency, and evaluation. 


1. Feature Implementation 


= a SS ee Se = == GSE SSS Ee SS SS SS 


The major objective in this work was the construc- 
ieen OL working prototype interpreters for the language. A 
progressive schedule was develofed that sought to implement 


the £fecllowing features: 


e Canonical Rules. This phase includes the development of 


the inguiry, absence, assertion, and deletion functions 


for kasic rule interpretaticn. 
e Function definition and evaluation. 


e Procedure calls. 


Be. 


e Cancel operations. 


e Sequential blocks. 


2. Relation Representations 


Relations and the operations defined on them are the 
central components of the Omega systen. To support flexi 
bility in relations, a variety of representations is desir- 
able. Such representations could range from a Simple list 
structure to a relational database management system (DBMS). 


To reduce the prcblems associated with multiple representa- 


tion, the relation interface must be clear: an abstract 
data tyre, With primitive oferations defined for data 
access. 


je  EELacirency 


The Omega language was developed aS a general- 
purpose language, carable of frototyping programming envi- 
ronments anda variety of system-level functions. Tha 
orientation makes execution efficiency an important imple- 
mentation issue. The goal was to obtain a level of 
efficiency comparable to a LISP systen. 

Efficiency was considered mainly in terms of execu- 
tion speeds. In those cases where a space-for-time trade- 


off was available, it was made. 


i. VEvailuation 


ee ee ee 


The final goal for the prototypes was evaluation. 
This evaluation centered on performance: how control strat- 
egies and data structures affect execution time. A second 
evaluation area was to determine the utility of language 


features through programming experience. 
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IV. A LISP FROTOTYPE 


A. WHY LISP? 


The design issues for Omega led to the decision to write 
a guick prototype for the exploration of high-level design 
decisions. The high-level concerns were the interpreter 
organization, selection strategies for rules, and the repre- 
sentation of objects, relations, and directories. 
Efficiency was not a design goal for this prototype. 


Franz LISP was selected as the initial prototyping 


language. This selection was made for the following 
reasons: 

e Availability. Franz LISP was available onthe VAX 

11/780 system being used for this’ work. ie were 


familiar with Franz LISP, and the implementation is 
well-done. The system includes a reliable interpreter, 


compiler, and debugging package. 


e Symbolic facilities aid in yfattern-matching. Tne heart 
of the Omega design is the pattern-matching process. 
The symbolic manipulation facilities of LISP allow these 


algorithms to be programmed guickly. 


e Dynamic typing. The dynamic typing or LISP corresronds 


weli with the tyfing of Omega. 


e Memory manayement. Memory management is transparent 
under LISP. While these issues can impact heavily on 
System performance, they are complex and distracting to 


early prototyping. 


e Debugging. Tne debugging facilities of Franz LISP are 


excellent, and superior to any other development 


Sul 


environment available at the time. In a prototypang 
project, extensive debugging is essential to cope with 


constant design and coding changes. 


B. ORGANIZATION 


The interpreter is organized like a classic LISP inter- 
preter. The organization is based on the description given 
in Chapter 11 of [Ref. 19}. 

The top level consists of a read-evaluate-sweep loop. 
The read function 1s a command rule parser. Commands are 
entered at the terminal, parsed, and an instruction list is 
generated. This instruction list is passed to the evalua- 
tion function for execution. The sweep function processes 
any active rules that are ready to fire after the actions of 


the read-evaluate phases are cougplete. 


C. THE LEXICAL SCANNER AND PARSER 


The reader consists of a lexical scanner and parser. 
Instead of evaluating input as LISP expressions, the reader 


accepts free-format input using tne Omega grammar. 
1. The Lexical Scanner 


A character reader function 1s used to pass awa 
of characters to the scanrer. This reader function uses the 
character input facility of Franz Lise | Regoueae pp. 
Seats As each character is read, it 1s added | towan 
input character 1ist. The complete character list 1s 
passea to the scanner. 

The scanner processes the input character jist to 
recognize tokens. When recognized, a character list is 
compressed into a token (LISP atom) using the implode func- 


tion [Ref. 20: p. 2.711]. The final output of the Scannenee 
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a list of tokens built up in this manner. fists thts 
complete list of tokens that is passed to the parser. 

The token classes consist of identifiers, constants, 
and delimiters. Constants are limited to integers and 
strings. Once a constant token is recognized and 
constructed, a denotation function transforms the symbol 
into a LISP integer or string aton. 

The separation of the scanner from its supporting 
reader function allows the Same routines to read fron 
multiple sources. Two reader functions are used: one for 
console input and one for file input. The file input func- 
tion is used to support command rule entry from text files, 
Piiar to the load function cf Franz LISP [Ref. 20: p. 
De )~ 

When receiving console input, the reader needs to 
distinguish the end of input for a command. Successive 
Carriage returns are recognized as this termination 


@ondition. 


De the Parser 


A single-pass, recursive descent parser is used to 
process the token list produced by the Scanner. AS a 
construct is recognized, an operator symbol is_ created 
which, along with its operands, is added to the parser's 
output list. The parser receives a token list as input, and 
returns an operator/operand list as output. 

The output list for the parser is a Simplification 
of the abstract syntax for the language. Consider the 
following input: 


eho meno Xx) —> oho (x) 


This rule is reduced to a token list by the scanner and 


input to the parser. Plesvduscemollenure ror this rule would 


be the following LISP expression: 
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(CANCEL (INQUIRY (VAK "R1") (TUPLE (VAR "x")))) 
(PRESENT (INQUIRY (VAR "R2") (TUPLE (VAR "x")))) 
(ASSERT (VAR "R3") (TUPLE (VAR "x"))) 

) 


The sublists preceded with the symbols CANCEL, PRESENT, and 
ASSERT are termed instructions. A list of these instruc- 
tions is produced for every rule. 

These instructions correspond to the baSic actions 
that the interpreter must perforn. Besides the three 
instructions shown, this prototype produces similar instruc- 
tions for the deny operation (DENY). 


Subordinate instructions are created for operand 


generation and evaluation. In the preceding exampie, the 
sublists headed by INQUIRY, TUPLE and VAR fali into this 
category. Other subordinate instructions are included for 


constants (CON), rule denotations (DENO), and function 
application {APL). 


A subset of the original Omega grammar is recognized 


by the parser. The intent was to aliow the interpreter to 
evaluate the simplest canonical form of rules, which uses 
present/inguiry tests, absence tests, assertions and 
denials. 


The Omega grammar described in {Ref. 14] makes no 
syntactic distinction between the antecedent and conseguent 


of a rule. Thus, a rule would tLe written: 
Rl {%), RZ Gape—> She ae (Xe 


The convention of allowing the "->" to be omitted in a 
command rule requires an indeterminate lookahead to decide 
whether the antecedent or consequent portion of the rule is 
being parsed. If the "->" is omitted, every token in the 


input list must be examined. 
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(Wtomopoclem is solved by, a4 pre-scan of the token 
list before parsing. feeGrhe texen list doesn't contain the 


">" token, it is inserted at the beginning of the list. 


De. RULE EVALUATION 


The interpretaticna of a rule is done by an iterative 
execution function anda subordinate recursive evaluation 
function. The execution functicn steps through the instruc- 
tions ina rule and passes them to the evaluation function. 
This separation into iterative and recursive functions is 
done to facilitate backtracking. 

The evaluation function returns a value of "true" or 
Beatse." if an instruction is evaluated "false," the execu- 
tion routine resets any temporary bindings associated with 
that instruction's predecessor, then attempts to re-execute 
the predecessor. The rule faiis when this process backs up 
to the initial instruction. It succeeds if all instructions 
succeed. 

At tne level of the execution function, there is no 
distinction between the conditicns of the antecedent and the 
actions of the conseguent. Backtracking is only meaningful, 
however, in the antecedent portion of the rule. Therefore, 
the evaluation function always returns "true" for instruc- 
tions generated from the consequent of a rule unless an 
error is detected. 

An instruction history list (a stack) is maintained to 
ea@pport backtracking. lied ea@ektrack 1S pequrred, the 
pointer to the predecessor instruction is popped from this 
bast. If the instruction succeeds, the pointer for the 
instruction is pushed on the list. 

A binding history list (another stack) records the 
logical variable bindings being made as each instruction is 


evaluated. Pacimmelictmvuect1 on tails, the bindings of its 
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predecessor are popred from the binding history list and 
undone. If an instruction Succeeds, any free variarle bind- 
ings made during its evaluation are pushed on the binding 
history list. 

The cancel operation requires the generation of a DELETE 
instruction should the cancel evaluate as "true." <A delete 
list 1S Maintained for this’ purpose. To Support bag 
tracking, the delete list 1s checked for duplicates before 
adding instructions. The instructions in the delete list 
are passed to the evaluation function after all the instruc- 


tions for the rule have successtiully executed 


1. Instruction Evaluatuoen 


The instruction evaluation function performs a 
direct interpretation of the instructions produced by the 


parser. The steps of the function are simple: 


Vaul(eacie 
return Op [ Eval[ ol, 02, = = <7 (Ona 
where Op is the cperator of 1 and 
<Ole 2 dos on> are the operands of 1 
end Eval. 


The function recursively evaluates the operands of an 
instruction, then appflies the instruction's operator to the 
result. To support this organization, a LISP functie@nmee 


defined for each operator. 


2. The Applicative Component 


The applicative compcnent of Omega is Simply 
supported by £Eunction definitions Sireleor. Such £unctions 
are invoked by the APL operator, which is passed the func- 
tion name and its arguments. These symbols are directly 


interpreted by LISP, and a resuit produced. 
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This applicative mechanism bypasses some important 
issues which a non-LISP implementation must consider. These 
issues include function definition at the rule level and the 
interface between the object-oriented and applicative inter- 
preter wtechanisms. 

ioeolmolted ty | Wath which new functions can be 
defined to support the Omega interpreter gives this imple- 
mentation a strong reliance on functions. Consider’ the 


implementation of a rule for Display: 


Pease DIS pay (x) —> 
Nubile Print( xj) - 


mre function call Print; x] is translated directly to the 
feoP print function. Null is a dummy relation whose only 
purpose is to allow the print function to execute. 

In the above example, the use of the Print function 
is inconsistent with the philosophy behind the applicative 
component of Cmega. The LISP print results ina side 
effect, and is therefore not a pure applicative expression. 

The print mechanism is more accurately nodeled 
through relations. A functional implementation is forced in 
Situations such as this to allow access to LISP definitions. 
The conseguence of this "bending" of the semantics of the 
language is shown by the appearance of awkward constructs 


such as the Null relation. 


Ee Cbhiects 


An object in Omega 1S used aS a place-holder in 
relations. To fill this role, the fundamental character- 
istic of objects is uniqueness. This was easily implemented 
iowmrd the gensym function of Franz LISP {[Ref£. 20: p.j 2.8}, 
which returns a unigue symbol each time it is called. A 
functicn to create new object identifiers needs only to make 


successive calls to gensyn. 
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4. Relations 


Relations are represented as objects which have an 
associated list of tuples. The relation object identi- 
fiers are created through the gensym mechanism previously 
described. A value is bound to the symbol using the set 
LUNCTION CL Lise. 


10 illustrate this representation, consider the 


following sequence of command rules: 


Define (root, "Ri", Newrel[ }).- 
R1 Cla tp ee. 


RZ ny, Zant) a 


The Newrel[ ] function returns the object identifier for the 


new relation. After the assertions, the relation R1 


CONnSiSts Oo: the tolPowing: 


( 
Cat! Wp tc i) 
( ity t yn ee wt) 


) 


The relation is a list of tuples, each of which is a iigere 


With the iist representation for relations is a set 


of management routines. These routines are match, add, and 
delete. 

The match function provides the mechanisn for 
pattern-matched inguiries. The function 1s constructed as 
foliows: 


match{[ RelationName, Tuple, Index] : 
1£ Index = Nil 
R := get binding of Relation Name. 
else | 
Ros — Ende 
endif 
while R <> Nil 
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end w 
retur 


end matcna 


The match_egual 
Sive list equa 


unbound variabl 


Match_equa 


ie RI 


else 


else 


else 


else 


else 


end match_ 


The mat 
melation. rac 


fe tound .or th 


if-match_eyual[ farst[ R], Tuple] 
return KR 

sem es =o ci nh | 

hile 

n FALSE 


function 1S a modified version of a recur- 
tye LOS te A modification is required for 


es. The algorithm is: 


eR geeks jas 

=Nil and R2=Nil 

return TRUE 

tent —Ni wor RZ = Nil 

return FALSE 

if R1 is UNBOUND 

return TRUE 

1f R1 is an aton 

return R1=R2 

Li suscenmecud WErIrstip i), Lirst, RZ] |] 
return match_egqual(rest[Kk1], rest; R2]}]} 


return FALSE. 


equal. 


ch function performs a linear search of the 
h tuple is selected and tested until a match 


e list of tuples is expended. The index 


parameter passed to the match function indicates the foint 


in the relation 


where the search is to begin. this irdi— 


cator iS non-nil when the match is being requested on a 


backtrack atten 
The mat 


matching algori 


jee 
ch_egual algorithm is similar to the pattern- 


thm discussed in the previous chapter. Tn 
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match_equal, however, no variable binding is done. Instead, 
variable bindings are made after match_equal returns its 
result. 

The add function places new tuples at the beginning 
of the relation list, making the relation list a LIFO struc- 
ture. The delete function removes a tuple directly from the 


relation 11st. 


Sra) Ae Gl ema 


Variable binding is controlled by symbol tables for 
temporary and global bindings. These symbol tables are 
implemented as association lists, and are manipulated 


through the follcwing management routines: 


e Add. Install a symbol and its definition in the symbol 
table. 


* Delete. Remove a symbol and its definition. 


e Lookup. Given a symbol, searcn the table and return the 


definition. 


The use of association lists for symbol table repre- 


sentation is not the most efficient method provided by LISP, 


but dces offer some advantages. The representation is 
Simple, and the taktle contents can be easily inspected 
during debugging. Also, there 1S a close correspondence 


between these association lists and the structure chosen for 
relations. 

The correspondence between symbol tables and rela- 
tions allows the direct implementation of directories as 
relations. The directory prevides an environment which 
binds variables during rule evaluation. 

To support the use of multiple directories, the rule 
structure was expanded to include an environment pointer for 


each rule. This environment pointer represents'7 the 
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directory to be used for variabie lookups. A rule, then, is 
represented as a pair: <ep, ifp>, with environment pointer 
feeyoeeaua adh Instruction pointer (ip). This representation 
is called a closure, andis atechnigue used to simulate 
Beadtic Variable birding in LISP systems [Ref. 19: pp. 
436-37]. 

To support temporary kindings mage by pattern- 
meechang, a local symbol table is used. The evaluation of 


variable bindings follows the following sequence: 


e When arule begins execution, a global environment 


pointer is set to the environment pointer for the rule. 


© To evaluate a variable, the local symbol table is 
searched for a frevious definition. If not already 
defined, the directory referenced by the environment 
pointer is searched for a global binding. be Global y 
bound, the variable and its definition are instalied in 
the local symbol table. 


e Tf not defined in the local symbol table or in the 
rule's directory, the variable is considered unbound. 
This is represented by the installation of a special 
"unbound! definition in the local svmbol table. 


Variable binding details are external to the rela- 
tion management functions. Berore passing a tuple to the 
Matco function, lookups are made in the local symbol tabie 
and variabies replaced by their definitions. The match 
function accepts this tuple as input, and returns a pointer 
to the corresponding relation tuple if a match is found. 
Free variables become bound by having their match counter- 
parts added as definitions in the local symbol table. 

The isolation of the relation match function fron 
variable binding simplifies the interface between the rela- 
tion management routines and the evaluation function. This 


Simplistic approach is flawed, however. 
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Consider the following rule: 
it *Ri(x, xX, Yu 2, eee 


Assume the relation R1 only contains the tuple <1, 2, 3>. 
Using the match algorithm previcusly described, the pattern 
<x, X, y> would successfully match against <1) 27 Lo 
prevent such an error, the match algorithm must take tempo- 
rary bindings into consideration. This requires an exposure 
of some of the details of the binding mechanism to the rela- 


tion management routines. 


E. CONTROL 


Active rule interpretation cccurs during the sweep phase 
of the interpreter's top level. This prototype uses the 
Simplest possible control strategy for rule selection: each 
active rule is tested on every cycle. Active rules are 
Maintained ina list, and the execution function is mapped 


to each of the rules. In LISP terms, this is written: 


(mapcar * (lambda (rule) 
(exec (car cule) (cadr rule))) 


ActiveRuleList) ) 


The lambda function splits each active rule into 
instruction and environment comfonents. 

After each cycle, the above sequence returns a list of 
results from each application of the execution function. 


The result for a cycle appears as: 
(t t mal nil tno ee 


where each "t' response comes from a successful rule execu- 
tion. The sweep phase will ccntinue to cycle through the 
active rule list until all rules retutn a "nil" response. 


At this point, the active rule list is in a quiescent State, 
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and additional cycles will not produce any new state 


mf Ormation. 


F. ERROR CONDITIONS 


Binding requirements differ as rule evaluation proceeds 
from the antecedent instructions of the rule to the conseg- 
uent instructions. These requirements constitute a signifi- 
cant source of error. | 

In the antecedent, the members of a tuple may or may not 
be bound. An unbound variable at this point is not an 
error, unless the variable is involved in an appiicative 
expression. In the consequent cf a rule, all variables nust 
be bound. Unbound variables at this point are reforted as 
an error. 

The binding for relation names is more strict. Given a 
left-to-right evaluation of instructions, each relation name 
must be bound before its evaluation. 


Consider the rule: 


Paes ex (Vy yp Kj) > «6 « 


The evaluation of relation R occurs first. The variable R 
must be globally bound, or an error will occur. asa 
contrast, the variable x is bourd in tne R(x) inguiry. Its 


later use as a relaticn name is valid. 

The reguirement that relation names te bound is an 
implementation restriction. A more general mechanism would 
allow a sequential search of all relations in the database 
for trial bindings of relation rames. This would extend the 
free variable binding process previously shown only for the 
tuples in a relation. 

A simple error-handling approach is used in this system. 
When an error is detected, a wessage is displayed and the 
interpreter continues with the evaluation of the next 


frstruction. 
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Gs AY B00t syslau 


After the implementation of the basic rule interpreter, 
it was necessary to identify a ginimunm set of definitions to 
Support a working system. When such a system becomes opera- 
Pom da, additional features can be added through rules 
defined in Omega. 

The Foundation of the naming mechanism is the Define 
relation. No rules, relations, or constructs may be added 
to the system without the use of Define. To accommodate 
names that are added as the system grows, a Minimum of a 
Single directory is necessary. 

In this prototype, a root directory, defined in LISP, 
contains the initiai bindings required by the interpreter. 
The root directory initially contains the bindings for the 
Define relation and the active rule list. This directory 
also contains a reference to itself: a binding for the name 
"EOCGE. | 

To support the definition cfr system functions in LIS?, 
the names of these functions are pre-defined at the time of 
system initialization. 


The initial root directory appears as: 


(setg root '{ 
(MROOE LEGO) 
(NActiveRules™ Actavetutes) 
(“Cons scons) 
(ita © Ste au) 
(MRCS ces cag) 
("Append" append) 

) 


This association list binds the Omega names to the appro- 


priate LISP symbols. 
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When the interpreter begins execution, the following 


events occur: 
Mince root Girectory 1S Loaded into LISP. 
e An Omega initialization file is parsed and evaluated. 
e The interpreter begins its read-evaluate-sweep cycle. 


The initialization file ccntains Omega command rules 
that allow the implementation of system functions with 


rules. These rules are defined by the foliowing assertions: 


Root ("Activate", Newrelf[ }). 


ActiveRules (Parsef Fread{"sysgen.rul"])}). 


The assertion to the ActiveRules relation initializes the 
system's set of active rules to those contained in the file 


“sysgen.rul." These initialization rules consist of: 


if *Define(dir, name, def) -> dir(name, def). 
if *Activate(newrules), *ActiveRules({oidruies) -> 


ActiveRules (Append[oldrules, newrulesj). 


These rules and definitions are sufficient to set upa 
Minimum systen. As shown by the rules for Define and 
Activate, it is possible to express system functions as 
rules. To expand these functions, more ruies nay be defined 


and added to the active rule list. 


He. LESSONS LEARNED 


This early prototype was instructive, both in those 
functions which worked well ard in those functions which 
performed poorly. 


The major benefit was the implementation of a top-down 


design. The read-evaluate-sSweep cycle demonstrated that a 
recursive, LISP-like interpreter design was useful for 
Omega. 
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The prototype implemented a simple list representation 
for relations, and assisted in the identification Of pring 
tive operations reguired to manipulate freiations. Of 
particular interest was the pattern-matching algorithm. 
While the implementation was flawed, the basic algorithm was 
useful in the follow-on prototype. 

The iterative backtracking algorithn was more complex 
than necessary. The stacks used to support backtracking 
suggested a recursive algorithm as a possible alternative. 

The design chosen for the parser was a poor one. The 
steps of creating a character list, then a token list, and 
finally an instruction iist, were time consuming. The 
requirement to scan the token list for the presence of the 
"->'" token worsened the already poor performance of the 
parser. 

The interpreter used the crudest possible control 
strategy, and tested every rule on each iteration of the 
sweep cycle. This ccentrol strategy has the obvious advan- 
tage of simplicity, but the performance is unacceptable. 
The control strategy, together with the slow parsing Speeae 
resulted in a sluggish system response, even with a small 
number of active rules. In one test case, the parser 
required 13 seconds to process a 33 line rule file; with an 
active rule list of about 20 rules, a simple Display conmand 
took 2 seconds to execute. 

It was anticipated that the performance of this proto- 
type would be poor, and so it was. This is not a reflection 
of LISP as an implementation language. No attempt was made 
to write efficient LISP, and substantial improvements can 


probably be made. Potential areas for improvement are: 


e An improved parser. The character i/o in Franzgieoe 
lends itself to the inefficient implementation used in 


the prototype. A possitle improvement would be a 


DIZ 


Scanner amd parser written in C, and integrated into 


Franz LISP as a foreign function [Ref. 20: pp. 8.4-8.8]. 


e Improved control strategies. More precise rule selec- 


tion strategies impact heavily on performance. 


*® More efficient LISP. Franz LISP offers alternatives to 
the simple list structures used in this prototype. An 
analysis of the prototype performance could be periforned 


to pinpoint areas for LISP code optimization. 


The LISP prototype was intended to be a_ throw-away 
implementation. While numerous improvements are possible in 
this prototype, tne performance of the LISP interpreter 
becomes a final limitation. An implementation in a lower- 
level language offers the potential for data structures, i/o 
facilities, and memory management technigues that are more 
closely tuned to the requirements of Omega. 

An important decision in the life of a throw-away proto- 
type is when to stop. This prototype was abandoned aiter 
the isgplementation of a limited but fundamental set of 
features. The prototype was revised numerous times, but 
with a minimal expense in coding time and implementation 
complexity. While many aspects of the interpreter design 
changed in the follow-on implementation, the contributions 


of this prototype to the next were substantial. 


a 


Ve. A FOLLOW-ON IMPLEMENTATION IN C 


so. WHY Cz 


The second prototype was written using the C language, 
although other alternatives were available. The decision to 


to use C was based on the following: 


e High level control structures. The language has a 
reasonable set of control structures that Suppeime 


modular programming. 


e Simple but flexible data structuring. C supports wa 
limited but flexible set of data types and constructors 
that are well-suited for interpreter implementations. 
The bit-level operations and weak data typing provide 


Opportunities for space and speed optimizations. 


e® Recursion. C is a recursive language, and many of the 
algorithms explored in the LISP prototype were easily 


translated into recursive, © VeEocuons 


* Integration with UNIX. As with the LISP prototype, the 
follow-on was developed on a VAX-11/780, using Berkeley 
UNIX (35D 4. 2) 2 No language is better suited to UNIX 
than Cp and vice versa. the operating system provides 
many features that directly support access to. system 
routines and variables. Tne numerous software develop- 
ment tools available on a UNIX system are largely 


intended for use Ey C programmers. 


C is not a perfect implementation language by any means. 
The availability of low-level cperations and type coercion 
provide a dangerous source of error and confusion. The 


terse syntax is difficult to read for those unfemiliar with 
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the language. HiitiiVqume smestriecrt use of Calli-by-value 
morCes ag proliferaticn of pointer usage, complete with a 
flood of subtle errors resulting from pointer abuse. 

Despite its limitations, Cis a tool well-suited to its 


environment. 


B. CHANGES TO SYNTAX AND SEMANTICS 
1. An Antecedent Keyword 


The previous chapter discussed the problem caused by 
the optional "->" sign in the Onega syntax. The problem was 
circumvented in this implementation by the use of the 
keyword "if" to Signify the beginning of the antecedent of a 
rule. A one token lookahead is suificient to detect this. 

The original Omega syntax uses the "if" keyword to 


signify a constraint. Thus a rule would be written: 
meee =n) pe lieX > Y => s a « 


Syntactically, the keyword is nct necessary to distinguish a 
eonstraint. Therefore, the use of the keyword was modified 
to solve the lookahead proplen. Heong) tars modirica ti on, 


the rule is written: 
Ree tx), *R2¢(y), X > yY -> - - . 


The semantics are unchanged. 


The delimiters for a rule denotation were originally 


asymmetric quotes. This was modified to the <<. sea 
construct shown in previous’ chapters. This syntax was 
selected wou zaad greater visual emphasis for rule 
denotations. 


2D 


ar 


(td 


use Separators 


A small but important modification was made to the 
use of the period and comma as delimiters. MacLennan uses 
the semi-colon to separate rules within a sequential block, 
and a period is used for the separation of rules ina deno- 
Tallon. This distinction is made to emphasize the sequen- 
tial nature of the block in comparison to the concurrent 
nature of the rules within the ruie denotation [Ref. 14: p. 
23}. 


This distinction was altered to solve the command 


rule termination problen. Rules are always separated by 
Semicolons; a period indicates the end of the current 
command rule input. This replaces the dual carriage return 


termination of the earlier protctype. 

This problem results from the use of rules as a 
command language. Rules tend to span multiple lines, soa 
Simple end-of-line termination is not sufficient to indicate 
the end of input. Two alternative solutions to this problem 
are: (1) terminate a multi-line command with a continuation 
character, or (2) use a special character to signify the end 

£ ibn pues 

The latter technigue was selected, with some loss of 
the useful syntactic distinction between denotations and 
seguential blocks. It 1s hoped that the remaining diS vies 
tions between the two constructs, <> severe 3's, are 
sufficiently different to serve as a reminder of the differ- 


ences in semantics, 


4. Parameter Lists 


The original syntax for a function call was similar 
to the form of an assertion orf Vance. Thus a rule 


would appear as: 


Ri (x, YY) -> R2Z(COnS(X2a yi) 
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The square bracket notation for function parameter lists was 


selected to provide an obvious distinction between function 


Calls and other non-applicative forms in the language. The 
square brackets also denote lists, ZaEteorie Similarity 
emphasizing the Semantic connection between these 
constructs. 


A similar modification was made for the procedure 
call, where curly braces denote the parameter lists. This 
syntax appears unusual, and the procedure call mechanism is 
unusual. The semantic Similarities between the procedure 
call and the seguential block, both of which provide some 
degree of control on the otherwise free concurrency of 


Omega, is emphasized by their ccmmon use of curly braces. 


5. Conditional Expressions and Function Definitions 


The introduction of an applicative component into 
the language required syntactic extensions. These exten- 
Sions were centered around the conditional expression, which 


1s illustrated by the following rule: 
if *R1(x) -> R2( if x<3 -> "YES" else "NO" ), 


The value of the assertion is determined by the conditional 
expression. 

Given the form of the conditional expression, a 
function declaration can be formed by giving the function 


hane, parameter list, and body (a conditional expression): 
BieicxXiex,ey | s lf X > y —>. x else y. 


Syntactically, a function declaration may appear anywhere a 
command rule would aprear. 

The form of the conditional expression is a modifi- 
Cation to the original syntax of the rule, with restrictions 


to prevent side effects. 


Sy 


- 


6. An Implicit Response £or Commanagiutes 


A syntactic change was made to allow expressions at 
the same level as assertions. This modification allows the 


entry of the following command rule: 
if *R41(x). => eee 


When this rule is evaluated, the binding of x is "returned" 
by the rule. If this binding is printed by the interpreter, 
the necessity for ubiguitous "LTisplay" calls may be less- 


ened. This allows the command entry of expressions such as: 
2 +. 2)* oan) Pave 


where the interpreter returns the result. 


While this modification to the rule syntax is 


convenient for command rules, it provides some interesting 
semantic guestions. Suppose the following is an active 
rule: 


if *R1(x) -> 2 + 2. 


What does the conseguent of this rule mean? It involves no 
aiteration of the database, but instead requires an expres- 
sion evaluation. 

The action may be described by the following equiva- 


lent forn: 
if *R1 (x) (—-S¥bvali' 2 t+ eZ oe 


The expression is asserted to an iuplicit Eval relation, and 
the semantics of the procedure call apply. Note that, in 
general, the value returned by a procedure call used at this 
level is ignored. For command rules, this value may be used 
to indicate the result returned from evaluating a rule. 
Given this interpretation, consider the following 


rule: 
if *R1(x) -> R2 (x). 
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What is the "result" returned ry the assertion? A simple 
convention is that that the assertion of a tuple x toa 


relation R returns the tuple x as its result. 


A final added feature is a head/tail pattern speci- 


mecaticn for lists, similar to that of Prolog [{[ Ref. 21: p. 


43]. This is shown in the following rule: 
tare (et 1) > Re(n), RZ (t) « 


mie [hs:t] notation will match a list. The variable h will 
be bound to the head (first) Gevene J1st; the variable t 
will be bound to the tail (rest) of the iist. 

The head/tail specification syntax is extended for 


tuples: 
Pierre (net) => RIGh), R2Z(t). 


This notation provides a pattern specification for tuples 
that is independent of tuple cardinality. This generality 


was not possibie using previous constructs. 


C. DATA STRUCTURES 


Data structures posed the major design challenges for 
this interpreter. The structures of varticular interest 
were the representations for rules and for supporting the 


objects and values of the language. 


1. A Uniform, Tagged Lis 


A list structure, Similar to that of LISP, was selected for 


the representation of rules. This structure was selected 


for the following reasons: 
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e Rules are represented as Dindiyeec eco Using a list 
structure for rules allows a direct, recursive evalua- 


tion technique Sipilar to that of the LISP prototype. 


e Omega needs iists. Lists provide a general constructor 
mechanism that 1S extremely Ilexible. In a pattern- 
matching language, iist structures are essential if 


pattern-matching is to extend beyond character strings. 


e Uniform list structures sinuplify design. Given that 
lists are desirable as a data type within the language, 
a Simple set of list handling routines suffices for 
analysis and syntnesis of data within the interpreter. 
Uniform list structure alsc allows storage allocation 
and reclamation to concentrate on a Single unit: the 
last ceili. 


A diagram of the basic cell structure is shown in 
Figure 5.1 The cell has three fields: a tag field, a head 
field, and a tail field. Table I shows the types of values 
that each field may assume. 

The atomic values in this implementation are char- 
acter strings, Signed integers, and objects. These atoms 
are represented by cells. The type of an atom, aS witheee 
celis, is determined by the value of its tag field. 

Integers have their values contained directly in the 
head field of a cell. Likewise, opjects have their identi- 
fiers encoded in this field. The width of this field is 32 
bits, determined by the VAX 11/780 word size. 

Character strings have a pointer inthe head field 
that references a contiguous block of string storage. 
Reflecting their C implementaticn, string storage areas are 
NULL terminated. On the VAX, NULL iS represented by a zero 


value. 


60 


ry omen came ime cee a sere ee 


TAG HEAD ASG 


apr A ert) 





Q 
| 
Figure 5.1 Cell Structure. 
A list cell contains pcinters in both the head and 
tail fields. There are two classes ot list cells: data 


list cells and operator list cells. These are distinguished 
by tag values. 

Data list cells are analoyous to LISP lists. They 
serve aS data constructors. Oferator list cells form the 
interior nodes of a binary tree representation for rules. 
Rules are transformed and evaluated as tree structures. The 
"instruction" concept of the prctotype was dropped in favor 
of a more uniform approach. Pligure, 5.2 tiiustrates the 
parse tree for a simple arithmetic expression. 

This tagged structure simplifies evaluation at the 


expense of storaye space. dimaividual tays are used for all 
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ET SCS 


head field: 
Contents 


cell pointer 
string pointer 


integer 
object id 
<block, offset> 


tail field: 
Contents 


cell fointer 


unused 


| 


primitive data types 


abstract syntax for rules. 


of 
Or 


node. 
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discussed below). 
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ope CONeSeES 


As in the LISF prototype, 


unigue identifier. 


over 40 in the current implementation. 
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TABLE I 
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In this implementation a cell 
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(The actual percentage is somewhat 
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Figure 5.2 Tree Representaticn for a Simple Expression. 


generated for an object and ar identirier embedded in the 
head field. Again the problem is how to manage the identi- 
fiers so that the are unigue. 

The approach ased is tc maintain an object count. 
Fach time anew object 18S reyuested, the object count is 
incremented. If the control of object identifier allocation 
remains centralized, the objects are guaranteed tc be 
unique. 

The generation of identifiers this way leads to the 
issue of object identifier management. What prevents the 
System from running out of unigue identifiers? What happens 


when the identifier space is exhausted? 
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A Simple strategy is to ignore these problems alto- 
gether. How long can the system generate identifiers before 
te Guns Olt - For a rough calculation, assume that a new 
identifier is generated every 10 miiliseconds. The head 
field which contains an identifier 1s 32 bits, so assume 29 
bits are available (the use fcr the remaining 3 bits will 
be discussed shortly). With these vaiues, the identifier 
space would be exhausted in 229 x 10 milliseconds, or about 
62 days. The management of object identifiers is nota 
major issue in this systen. Should a larsger object identi-~ 
fier space be needed, additional bits could be provided fron 
the tail field of the object cell. 

A small portion of the object identifier space is 
reserved for system use. In the current implementation, 
the first 64 object identifiers are reserved. The presence 
of a system object is easily detected by an examination of 
its identifier. 


3.4 )hasks laoles 


AS in the LiIS&e prototype, certain types of objects 
have values associated with ther. These values are managed 
in this implementation using a uniform hash table mechanisn. 

The hash table index is generated by a simple hash 
function. The algorithm is based on that given in [Ref. 22: 
Demelsa ie The hash function receives a pointer to a cell as 
an argument, and returns the takle index. The algorithm is 


as follows: 


hash{p] : 
1f p@ is an integer of objecumce 
return pdhead mod TABLESIZE 
else if pd is a string cell 
return sum[ pdahead] mod TABLESIZE 
where sun{s] returns the sum of 
the ASCII characters in the 
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Serio Ss 
else 
return 0 
endif 


end hash. 


Tis function is acrude hashing algorithm for string 


emeryes, with itS primary virtue being simplicity. Object 
identifiers are generated linearly, however. The direct 
hash off these identifiers should result in mininal 
collisions. 


The structure itself consists of a pointer table (an 
array), With a collision list maintained for each entry. 
The collision list links together a collection of header 
cells. These cells have a key field with alist cell 
pointer, a definition field with another list cell pointer, 
and a link field with a pointer to the next header ceil. 
Figure 5.3 illustrates this structure. 

To complete the hash takle description, a collection 


of management and access routines are used. These are: 


e Lookup. Given a pointer tc a cell, find an entry whose 
key field points to an equivalent structure. Tfyiround, 


return the definition pointer. 


e Install. Add an entry to the hash tabie. The hash 
table is searched for an existing entry with the same 
key value. If found, that entry is replaced. icin @ i 
found, the new entry is linked into the appropriate 
collision list. Note that key entries may be any struc- 


ture: objects, strings, or lists. 


e Delete. Remove an entry from the table. The table is 
searched for the key vaiue. If found, the entry is 


removed and its collision list is relinked if necessary. 
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Pigure 5.3 Hash Table Structure. 


Cbject representations are linked to object identi- 
fiers using these hash tables. The objects within Cmega 
that have representations are relations, directories, rule 
denotations, and functions. These entities are subject to 


temporal change, and thus have an object implemeuttation. 
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4. Relations 


—_——_a oS 


Relations are objects, Lut with a twist: they have 
access considerations. The access control mechanism is 
encoded directly into a relation's object identifier. Three 
bits of the identifier signify whether the relation is 
accessible for read, add, or delete operations. Wnen a new 
relation is created, an object identifier is generated and 
tne Capability bits all set tel, indicating full privi- 
leges. Subseguent operations may reduce the capability by 
copying the relation object identifier and zeroing the 
appropriate bits. This produces a second reference to the 
same relation, but with reduced access privileges. 

Relations are represented as lists, similar to the 
LISP prototype. As a tuple is added to a relation, a header 
cell is created for the tuple and linked in at the head of 
the existing tuple list (if any). A pointer to this list is 
bound to the relation's object identifier through the object 
table. The list representaticn of a relation is showr in 
Figure 5.4 


Sear DILLeCCLOL1LEeS 


Directories incorporate the hash table into the 
general list structure. A directory has two header cells: 
meelass link cell and a partition ceil. 

The class iink cell cortains a pointer toa parti- 
meon cell, anda pointer to the next class link cell ir the 
class. A lookittwpes path, then, may follow this chain fron 
directory to directory. 

The head pointer of the partition cell points to the 
Peevate partition, while the tail pointer of the cell pcints 
to the public partition. Each fartition is represented by a 
Single hash table. 
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Figure 5.4 List Representation for Relations. 


In this implementation, directories are represented 
differently from relations. This distinction was nade to 
optimize directory access by hashing, althouyh there is a 


loss of the generality enjoyed [ry the LISP prototype. 


D. ORGANIZATION: THE TOP LEVEL 


The interpreter's top level is sSiwilar to that of the 


LISP rLovoty ve. An added steéep--the print phase-—-resmiime 
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from the notion that a command rule "returns" a result. The 


top level, then, consists of a read-evaluate-print-sweep 
loop. 

The read-evaluate-print Fhases process the user's 
command entry at the terminal. The print phase provides a 


visual indicator that some activity is taking place because 
of the command rule entry. 
Suppose a user enters’ the following cule at the 


terminal: 
Pieeen eye => Re (xX), RS (3): 


The reader parses the expression, binds variables as appro- 


priate, and then passes the parse tree to an evaluation 


munct ion. The response from the evaluation function is 
displayed at the terminal. In this example, this response 
would be "3." When multiple expressions exist in the 


conseguent of a rule, the response from the last expression 
is displayed as the response for the rule. 

After the command rule has been evaluated and its 
response displayed, the interpreter begins its sweep phase, 
evaluating any active rules that are ready to fire. There 
is no implicit response from active rules: their purpose is 
to alter the database. At the completion of the sweep 
phase, the command loop returns to the reader and waits for 
the next entry. 


E. THE READER 


The reader waS a major weakness in the LISP prototype. 
While an efficient parser implementation was not a major 
design goal for this work, the slow, error-prone parser of 
the LISP prototype was frustrating to work with. 

A parser generator was used to create the parser in the 


second prototype. This decision was made with the intent 


oO 


that a reasonably efficient farser pe produced with a 


Minimum of time and effort. 
1. A LEX Scanner 


The LEX lexical analyzer generator [Ref. 23] as 
used to produce the code for the scanner. LEX accepts as 
input a file of rules described through regular expressions 
and their associated actions. The output from LEX agem 
table-driven scanner in C source code. 

the following seguence defines LEX actions for 


recognizing unsigned integers: 


geneare EOS 
int_con {f(a ganes 
fi Peon jae 
FeEcrurn (iN See he. 
} 


The return statement 1S an emtedded C language construct 
used to describe the required action by the scanner. In 
this example, INT_CCN is a constant used to represent the 
token. 

LEX iS an easy-to-use, sophisticated tool. With “ge 
previous experience, we snecified, generated, compiled, and 
debugged a LEX scanner ina few hours. The LEX speci fiilea. 


tion for Omega is contained in Appendix A. 
4- A YACC Parser 


The parser waS written using the YACC (Yet Another 
Compiler-Compiler) parser generator [Ref. 24]. Like lig 
YACC allows a high level specification for compiler actions. 
The output from YACC is a table-driven, LALR(1) parser. The 
YACC parser receives its token input from the LEX scanner. 

The following illustrates the YACC Specification £or 


an Omega assertion: 


0 


assertion emOLiucieyee | arguments %) * 
{ 
S$ = newcell (ASSERT, $1, $3); 
} 


Poditional rules are given for "primary" and "arguments." 
The newcell function generates a new cell with the tag 
ASSERT, a head pointer set to the value returned by YACC 
from parsing "primary," and the tail pointer set to the 
vaiue returned by YACC from parsing "arguments." 

The embedded C expressicn determines the actions of 
the parser if an assertion 1S recognized. The assignment to 
Ng$" defines YACC's response: this value is placed ona 
stack for use in other expressicns. In this implementation, 
the value generated for each rule is a cell pointer. When a 
form is parsed successfully, the YACC parser returns a 
Pointer to the root of a parse tree constructed this way. 
The YACC specification for Omega is contained in Appendix A. 

YACC 1S a more complex tool than LEX, and it has 
some idiosyncrasies. These include precedence specification 
for infix expressions and a preference for left-recursive 
grammar rules. 

Infix expressions may be specified in YACC Ly a rule 


such as: 
Gor > Cxpr OP expr 


| 
Such a specification is ambiguous, however. To remove this 
ambiguity, YACC allows the declaration of precedence rules. 


Thus a precedence rule of: 


GSleft ¥ 4 t . 8 
Mpert tx 0 ‘yt 


would establish the precedence of the arithmetic operators 


and resolve the ambiguities associated with the previous 
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rule [Ref. 24: pp. 14-15}. This scheme results ina flat 
grammar for expressions in YACC, where the precedence rules 
determine associativity and precedence. 

Certain constructs in Omega lend themselves to 
recursive grammar ruies. YACC encourages such rules to be 
Left=recurouve. Left-recursive rules result in a smaller 
parser size, and reduce the likelihood of an internal stack 
overflow when parsing a long sequence [Ref. 24: p. 19. ]. 

Consider the following, left-recursive specification 


fOr. ar list: 


list : expression 


J Jist ")* expression 


The parse tree generated by such a rule is shown in Figure 
5.5 Cne consequence of this fcrm is that the entire list 
must be traversed to access the head of the list, ah obvious 
disadvantage in list-oriented interpretation. 

To solve this problem while still respecting the 
YACC preference for left-recursion, a recursive transforma- 
tion is performed on parse _ trees. This transformation 
selectively changes left-recursive forms i Dio righes 


recursive forms. The algorithm is: 


ECLAnS CUE i ep bec cum, 

LE CUED =e) 
return Nil 

else if curr points tc an aton 
ECGvuurn Cure 

else if curr is not a left recursive form 
currdhead := rtrans”’ currdhead, Nil ] 
cCurrétail := rctrans[ cCurcpdcarl eee 


CTeEtCurYr Cure 


h := rtrans| CULE ch cad? seuers 
ie 


s= rtrans| Currdtarly ae 


ez 


SuEPahead “= tC; 
eClrratail <—- sored 
iene Nid 


return curr 


else 
Bet ine pon 
end if 
end if 


end rtrans 


Figure 5.6 shows the list after the transformation has been 
mpplied. 
The YACC parser offers several advantages to a 


Beototyping effort: 


* Development time. The high level of the specification 


for YACC minimizes the comrplexity of parser generation. 


We had a complete, functicnal parser working in three 


days. 

e Ease of modification. Experimentation with syntax is 
Simple: change the grammar rules, rerun YACC, and 
recompile the out;ut. The ease with which the grammar 


can be modified encourages experimentation. 


e Verifying specifications. Analysis o£ grammar changes 
is easy in YACC. If a change produces ambiguities, YACC 
wili report conflicts when trying to generate tke parser 
tables. This automated analysis is a strong point in 


favor of uSing a YACC parser. 


3- Console and Fil 


input 


AS in the LISP prototype, the same parser is used to 
read command rules from the console and from text files. 
This is implemented using the i/o redirection facilities of 
UNIX and C. 
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Figure 5.5 Left-Recursive List Representation. 


The scanner froduced by LEX accepts input’ from the 
Standard input file by default. To receive input fron 
another text file, the file is opened and the LEX inputyeaeee 
variable reassigned. This Simple techniyue allows the 


alternation of input between Several Sources. 
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Figure 5.6 Transforrmed List Structure. 


Fo. A KBECURSIVE PRETTY PRINTER 


The parser, along with the celi allocation routines to 
generate the parse tree, was the first system component 
developed for this implementaticn. A pretty printer was 
weitten at this point primarily to debuy the parser. 

The pretty printer is based on a larye case Statement, 


which selects the appropriate output form based on the tag 


1D 


of the current subtree. A section of the algorithm may be 


@esSecrrreda "as: 


pretty print) eee 

do case p@d@tag 

Case’ RULE: 
PELE ee sera 
pretty_print{ pd@kead ] 
Priel 
Pretty. prime eed ta 
Pore os | 

end case 


end pretty print 


Although the pretty printer originated as a debugging 
aid, the basic design of the tag-oriented case statement was 
almost identical for the central evaluation function. This 
pretty printer evolved into the Display mechanism for the 
interpreter. 


G. RULE EVALUATION 


Where the LISP prototype used a separate, iterative 
execution function for backtracking, the follow-on design 
useS a recurSive backtracking aiyorithn within a single 
evaluation function. 

As in the pretty printer, the heart of the evaluation 
function is a large case statemzent. The tag value of the 
form being evaluated determines the case selection. A 


section of this case statement nay be described as: 


eval[ip, ep] : 
do case ipétag 


case KULE: 
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result := rulef{[ipfdhead, ip@tail, ep] 
endsecase 
return result 


end eval 


AS in the LISP prototype, separate functions are derined for 
the majority of interpreter actions. The function rule is 
defined externai to the case statement, and contains code 
for the interpretation of the RULE operator. Separate calls 
to eval are used to evaluate the arguments to rule. 

The evaluation function receives two arguments: a 
pointer to the subtree being evaluated (ip), anda pointer 
to the current directory for giobai name definitions (ep). 
The evaluation function returns a cell pointer as its 


mesult. 


H. BINDING 


i. Binding At Activation 


This implementation uses an entirely different 
binding mechanism than the LISF prototype. The variables of 
a rule denotation are bound when a rule becomes active. 
These bindings are determined by the environment of activa- 
tion. Since a command rule is immediately executed, binding 
takes place immediately for these rules. 

The binding frocess resultS in a complete copy of 


the parse tree for a rule, leaving the original denotation 


unaltered for iater use. In this way, the denotation is 
like a source file, the bound parse tree like an object 
file. 


When a rule denotation is bound, the current direc- 
tory is searched for variable definitions. The class of the 
current directory provides a search path to other directo- 


ries if the variable is not bound in the current directory. 


ad 


A variable not defined in the directories of the 
class is a free variable. The cell representing a free 
variable contains an ofiset in the head field, and a pointer 
to the variable's print name (a string cell) in the tail 
field. The offset for a variable depends on the order in 
which the free variables of a rule appear. 

When a free variable celi is initialized, a pointer 
to the variable cell is installed as the print name's defi- 
nition in a local symbol table. Subsequent occurrences of 
the variable wili be replaced by this definition. 

During the binding precess, the parse trees for 
embedded rule denotations are installed in the object table. 
A system-generated object identifier replaces the rule deno- 
tation subtrees in their parent expressions. The variables 
in the ruie denotation are left unbound--the binding of 
these variables 1s deferred until the denotation is 
activated. 

The final action for the binding process is the 
creation of an allocation operator cell for the rule. This 
cell has a count of the total number of free variables for 
the rule in its head field. The taii field contains a 


pointer to the actua Perule suri crime 


2. A Binding Stack 


The allocation operatcr is used with a binding 
stack. The binding stack 1S an array with a current frame 
pointer and a chain of dynamic link pointers that conmege 
frames. The binding stack is illustrated in Figure 5.7 

When a rule begins interpretation, a stack frame is 
created on the binding stack with slots allocated for each 
free variable in the rule. The offset in a variable cell 
indicates which of the binding frame slots is to be used for 


that variable. 
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ELQuee 5. 7 The Einding Stack. 


1s 


Toe binding process uses the following primitive 


routines: 


* “Dina i t,o ay}. The frame slot for variable x is assigned 


POLNTCE: ¥- 


e getbinding[ x}. Return the value in the frame slot for 


Variable x. 


e freebinding[x]- Free the binding for variable x. This 


is accomplished Ey assigning a reserved value to the 
Irame slot meaning UNBOUND. 


When a rule ccmpletes execution, tne dynamic link is 
followed to the previous frane, and the current frame 
pointer reset. 

The binding stack offers several advantages. First, 
variable lookups are only done once: at activation time. 


The dynamic binding process is only concerned with a vari- 


able's offset inthe stack frame, not with the variable 
name. The binding stack allows the simple reclamation of 
Storage used for binding. Finaplany, it allows context 


Switching in rule interpretation since bindings from iater- 
rupted rules are preserved. 
A context switch for a rule occurs during a syne@heoe 


nous cail. Consider the following rule: 
if *R1(x) -> { RZ{x}; R3{x} }- 


When the R2 procedure call is made, a context Switch is made 
to the body of rules that support the call. The bindings 
the variable x, however, must be maintained between the R2 
procedure call and the R3 procedure call. 

This method of static binding eliminates unnecessary 
variable iookups by replacing variables by their defini- 
tions. Generality is still maintained for objects such as 


relations, whose associated values are determined by dynamic 
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Toomupseii the Object table where necessary. Thus, ) the 
philosophical differences between objects and values in 
Omega are Supported by concrete differences at the implemen- 


tation level. 


Ie BACKTRACKING 


A recursive backtracking algorithm is implemented with the 


conditions (CONDS) operator. A condition is an element of 
the antecedent of a_ rule: a presence/inguiry test, an 
absence test, or a constraint. Backtracking is initiated 


only on the failure of a presence test. The algorithm is: 


conds[ cond curr, cond_next, ep] : 
Hatch next per r= Nid 
while TRUE 
result := eval[cond_curr, ep] 
Peeresult = FAIL 
return FALL 
else if cond_next = Nil 
return resuit 
end if 
result := eval{ccnd_next, ep] 
1f result != FAII 
return result 
endif 
PiTeEenencure is not a ‘*present* op 
return FAIL 
end if 
undo trial bindings made for condition 
end while 


end conds 


This algorithm treats backtracking as a binary operation. 


The "cond_curr™ parameter 1s the current condition heing 
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tested. The "cond_next" points to the remaining Liste 
conditions to be tested. A successful response from eval on 
"“cond_next" indicates that ali remaining conditions have 
tested successfully. A failure means a backtrack attempt 


should be made on the current ccndition. 


Je. RELATION MANAGEMENT ROUTINES 


The relaticn management routines of the LISP prototype 
are continued in this implementation. They are: match, 
add, and delete. As in the LISF prototype, the add function 
links a new tuple at the beginning of the relation list. 
The delete function removes the tuple from the relation list 
and relinks as necessary. 

A pattern-matching algorithm is used in the relation 
Match function. AS in the LISP prototype, the tuple list of 
a relation is searched linearly. As each tuple is seiected 
for a match, it is passed to the pattern-matching function. 
The match function maintains a "match_next" pointer. This 
indicates where the last match occurred, and provides a 
search continttation point £Or backemacking: 

The pattern-matching algorithm 1S similar to that given 
1m Cha pteewiir. Unlike in the LISP prototype, trial jyamaee 
able binding occurs during pattern eiatec ing. The pattern- 
matching function binds free variables by using the bind 
operator oi the binding stack. These bindings are undone if 
a rematch is necessary when backtracking. 

In this implementation, relation access cCOntrOi ire 
enforced. The object identifier for the relation is first 
tested to ensure the capability bit for the desired opera- 
tion is set. If not, the operation is canceled and an error 
message is generated. 

An additional relation function was added: match first. 
This function returns a pointer to the £irst tuple ia 


Relation. 
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Ke ACTIVE RULE PROCESSING 
i; Iregqgers 


The technigue of triggering is used to improve the 
Pueetsion of active rule processing. The trigger for a rule 
is the left-most relation inthe the rule. For the 


following rule: 
ike *R V(x), SR2(y) -> . = 


the trigger is the relation Rl. 


Ppieemlewse Pectca ror test when certain events tak 


M 


(0 


place involving the trigger relation. These events ar 
assertions and deletions. If either of these operations is 
performed on the trigger relation, there is a likelihood 
that the rule's antecedent conditions are now satisfied. 

The triggering process iS initiated at the time a 
rule is activated. The trigger for a rule is determined, 
and the rule installed in an active rule table (a hash 
table), keyed by the object identifier for tne trigger rela- 
tion. A list is maintained in the active rule table for all 
rules associated with a given trigyer. 

When an assertion or dénial is made to a relation, 
any rules indexed by that relation are selected from the 
active rule table and tested. 

A rule is always tested at least once: when it is 
activated. This ensures that any pending conditions will be 


serviced before the rule enters its triggering cycle. 


Z2- A Rule Queue 


Triggered rules are managed through a circular 
queue. When a rule is triggered, a pointer to the rule is 
placed in the rule queue. 

During the sweep phase, all rules in this queue are 


tested. If a rule succeeds, 1t remains in execution by 


SS) 


staying in the rule queue. Instead of undergoing continuous 
evaluation, a successfui rule is reinserted at the end of 
the queue. This enfcerces a fairness policy: each rule 
the gueue should get a turn at evaluation. 

Given the nature of rule testing, only one instance 
of a rule needs to be in the gueuve at one time. Multiple 
instances will result in wasted interpreter cycles and 
excesSive gueue sizes. 

To control this probiem, a flag bit is used. The 
flag bit is contained in the tag field (bit 7) of the weageen 
cell in an active rule list. wmhen a rule list is placed in 
the queue, the flag bit is set. subsequent attempts to 
insert the rule list in the gueve will be ignored because of 
the flag bit value. When the rule list leaves the queue (by 
being selected for testing), tne flag bit is reset and 


subsequent queue requests for the rule will be accepted. 
3. Advantages and Disadvantages of Triggering 


Rule triggering has the following advanedge = 


“ 
tO 


recision. Tne likelihood of triggered rules firing is 


nN Wh 


ood. The strategy is much more precise than the global 
wW 


eep strategy of the LISP frototype. 


es Sitplicieys. The triggering mechanism described is 
sinple, both in concert and in 1ts SUpporpamg 


intplementation. 


e Triyyers are statically determined. The trigger is the 
left-most relaticn of wea rute. This iS a simple, 
syntactic distinction that is directly inferaniec meee 


the visual form of a rule. 


Despite its attractive aspects, the trigger meéecha- 
nism just described is too simple. To illustrate ime 


point, consider the following rule: 
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ier nies 2 (xX) =D PRZ (x). 


The intent of this rule is to enforce the constraint that R1 
should remain a subset of R2. 

Assume R1 and R2 initially contain the same tuples. 
If a tuple is removed from R2, the relation contents are 
different and the conStraint rule should fire. Given the 
previous triggering strategy, however, the rule will not be 
feaewecd. wane aritected relation twas R2, but the rule is trig- 
gered on R1. 


4, Two-Level Triggering 


A possible alternative to this Simple triggering 
method is to index a rule on every relation in the antece- 
dent. This will guarantee a correct evaiuation, but 
requires a compiex index structure. Aiso, Belg gering on 
secondary relations is inefficient--these relations may be 
updated frequently and result in excessive testing for the 
rule. 

Another possible alternative is to determine the 


poiat of failure. In the following rule: 
if *R1(x), *RZ({y) ->.-. .- 


the R1 inguiry may succeed and the R2 inguiry fail. If the 
me celation is flagged as the point of failure for this 
rule, a subsequent assertion tc R2 could be the trigger for 


a retest oi the rule. 


The diificuity with this strategy is determining the 
point of failure. Consider the following rule: 


ie Keaenh ( soeeo eR OS (kp Zl, KX > VY =P ucsos 


Each of the relations R1, R2, and R3 may have a tuple that 
meets the pattern specification. There is a dependency, 


however, among these inguiries and tke constraint. A 
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failure, then, may be a faiiure of the combination and not 
of any particuiar inguiry. 

A compromise strategy is used to solve tnis problem. 
We cali this technigue two-levei triggering. 

Using two-level triggering, two rule gueues are 
maintained. One is for active, triggered rules selected 
under the original triggering strategy. This is the primary 
rule gueue. The second gueue contains rules pending altera- 
tion of one or more conditions to enable firing. This is 
the secondary rule queue. 

when a rule is initially triygered, it is inserted 
in the primary rule gueue. isty, when tested, none of the 
conditions of its antecedent successfully match, the rule is 
discarded. 

If, on the other hand, at least the trigger condi- 
tion successfully matches (but the combination fails), the 
rule is entered inte the secondary gueue. The rules of the 
secondary queue are tested after the rules of the primary 
queue have been expended. 

Once inserted into the secondary gueue, rules will 
remain under evaluaticn for possible firing. A rule waa 


leave the secondary gueue under two conditions: 


e The rule fires and is transferred back to the primary 


queue. 


e The rule fails to match cn its trigger relation and 


leaves the active queues completely. 


TIwo-level triggering may be inefficient. Consider 


the following rule: 


if *Employee Data({name, salary), salary > 10000 -> 
Employee Data(name, salary/2). 


8€ 


If the Employee_Data relation is normally not empty, two- 
level triggering will perpetually maintain this rule in 
either the primary or secondary rule queues. If many rules 
behave this way, the rule selection strategy decrades toa 
global sweep, a worst-case perfcrmance. 

Many types of rules fair well under two-level trig- 
gering. The key to efficiency for this strategy lies in 
the use of the trigger relation. This relation should 


contain matching tuples only when the rule is ready to fire. 


L. THE APPLICATIVE COHUPONENT 


The original description cr Omega did not contain a 
detailed description of the applicative component. Instead, 
it assumed that a compietely separate applicative language, 
such as Maclennan’s A [Ref. 25], would be integrated into 
the Omega environment to support applicative evaluation. 

The applicative component was a minor issue in the LISP 
prototype, but the fcllow-on design had to resolve its role 


amd LOrm. Some of the alternatives considered were: 


e Develop a yeneral applicative interpreter interface. 


The Omega interpreter and arplicative interpreters would 


be Separate processes communicating through teenies 
interface. 
e Integrate the code iO an existing applicative 


interpreter into the Omega structure. 


e Use simple modifications to Omega grammar and semantics 


to add an applicative comporent to the language. 


The first option offers the potential for multipie eval- 
Heatwon functions. In one environment, an appiicative 
expression may be evaluated by LISP. Another environment 


may use an A interpreter. 
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This option was discarded for efficiency reasons. 
Applicative expressions use pointers to Omega structures, 
which implies shared memory access. Separate processes 
would have to pass this information through an i/o cpera- 
tion, such as a mailbox transfer or a UNIX socket [ Retlezage 

The second option was discarded because of complexity, 
and the third seiected for the same reason. Minor modifica- 
tions to Omega itself allowed the rapid development ofa 
Simple but useful applicative mechanisn. 

The only completely new language feature needed was the 
function definition, which has been shown in previous exaa- 
ples. A function definition takes effect at the same time 
rule variables are bound. 


The function definition performs the following actions: 


e The function name is bound to a system-generated object 


identifier and installed in the current directory. 


e The function is separated into a pair, <fp, b>, with 


formal parameters ({fp) and a function body (b). 


e The formal parameters are installed as free variables in 
the local symbol table. The variables of the body are 
then bound. These variakles will contain the stack 


frame offsets of their corresponding formal parameters. 


e An allocation operator is linked to the <fp, b> )jpaume 


This operator is used to create space on the binding 


stack for formal farameter kinding. 


e The function structure is installed in the object table, 


keyed on the object identifier. 


The function definition is different from the other 
features of Omega. The mechanism bypasses the "Define" 
procedure to allow recursive definitions. Note that the 


installation of the function name and object identifier into 
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mre CUErent Girectory is done first. When the variables of 
the function body go through the binding process, recursive 
references to the function name will be handled properly. 

When a function call is evaluated, the function struc- 
ture is retrieved frem the object table. The allocation 
operator is interpreted, and a frame created on the binding 
Beeck for the functicn's parameters. 

The actual parameters for the function call, previously 
evaluated, are grouped together in a list. This list is 
traversed, and tke pointer for each actual parameter is 
assigned to a slot in the current binding stack frame. At 
the completion of this process, all formal parameters are 
bound. 


The function body is then fassed to the central evalua- 


mron L£UnCtion. At this point, the function body is sinply 
another rule, and it iS processed by the rule evaluation 
routines. The binding stack supports recurSion in function 
evaluation. 


This applicative mechanism has the advantages of 


Simplicity and uniformity with the Omega syntax. Lie grunc— 
tion definition, however, does not conform well with the 
other constructs of the language. Also, lambda expressions 


and functionals--key components of an applicative language-- 
are not irplemented. 

Despite its limitations, a variety of interpreter 
utility functions were defined using this mnechanisn. These 


functions are listed in Appendix C. 


Me. PROCEDURES 


With the evaluation and binding mechanisms already 
introduced, the implementation cf a procedure call mechanisn 


is simple. The steps for procedure call evaluation are: 
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e Evaluate the tupie participating in the procedure call. 
This tuple is analogous to the actual parameters of a 


function call, and is implemented as a linked list. 


* Generate a new relation object for the mailbox. This 


object is linked at the beginning of the tuple list. 


e Assert the tuple into its target relation. The asser- 


tion mechanism will queue any ruies triggered as a 
result. 


e Execute tne sweep function to evaluate any triggered 
active ruies. The sweep function will continue to 


execute if there are ries torte. 


e Apply the match_first operation on the nailbox relation 
to extract the response from the call. It iS "Gia 
response that is returned as the result of the procedure 
Cait. 


While the procedure call gives a measure of control to 
rule processing, the mechanism is stiil unstructured. The 
philosophy of this implementaticn is "make the assertion and 
see what happens." One possible conseguence of the mecha- 
hism is multiple assertions to the mailbox. 


Consider the following active rule: 
1f *K{a}) —> alVYes"), ave oe 


if triggered as a result of a ~roccaurcycawm. what is the 
value returned by the call? The use of the match first 
operation and the ILIIFO implementation of relations will 
return the last assertion as the response. Other assertions 
are ignored. While this convention seems tractable, it is 


implementation-dependent. 
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Ne. BUILT-IN FUNCTIONS AND PROCEDURES 


While implementing the interpreter, the necessity for 
"hard-wired" functions and procedures became apparent. By 
hard-wired, we mean that these mechanisms are supported by C 
functions coded in the interpreter, as opposed to an inmple- 
mentation in Omega rules or functions. These mechanisms are 
built-in for purposes of efficiency. An example is the 
Define procedure call. 

In the LISP prototype, directories were implemented as 
relations and the Define mechanism was implemented with 
Omeya rules. By using different representations for direc- 
tories and relations, the Define mechanism has a dizrferent 
character that reyuires a more specific implementation. 

Names like "Define" are implemented as system objects. 
Recall that a block of object identifiers is reserved for 
system use. When a relation identifier is evaluated, systen 
objects are processed by a different set of routines: one 
for system-defined relations and one for system-defined 
munctlons. 

The object identifiers for these relations and functions 
are examined in a case statement, and the appropriate systen 
routine called. The routine for Define receives the parawue- 
ters (pointers) for the target directory, the name, and the 
@etinition. The entry is then installed in the hash table 
for the directory. 

The steps required to add a system-defined function are 


Simple: 


e An entry is made in tne object header file. This file 


contains the definitions of reserved object identifiers. 


e An entry is made in the case statement for the systen 


relation or function handler. 


of 


e A directory entry is predefined in the system initiali- 
ZatTOnenout Liter This routine builds the system's root 


directory. 


This mechanism ailows the access of system routines from 
Omega rules. The procedures for NewRel and NewObj are 
implemented in this way. Similarly implemented is the 
Display procedure call, which fasses a structure pointer to 
the system pretty printer. 

This system interface replaces the ubiguitous function 
definitions of the LISP prototyre. The process recuired to 
implement a feature as a functicn cail or procedure cail is 
the same; the mechanism may be selected that most appropri- 
ately models the desired activity. Appendix B lists the 


buiit-in functions and procedures for tne systen. 


O. CANCEL OPERATIONS 


The impiementation of cancel operations relies on two 
features of the interpreter: the "natch next" pointer gages 
a relation, and the binary backtracking algorithn. 

Tn tne hacktracking algorithn, a successful evaluation 
of the "next_condition" pointer indicates that the remaining 
conditions of the antecedent have ail been successfully 
evaluated. at this point in the recursion, a pointer to the 
Match position in the current relation is available if bpack- 
tracking 1S regquired. If the current operation is a cancel, 
the "match_next™" pointer references the tuple that should be 
deleted. This deletion is done directly by marking the tag 
field of the tuple. 

The tuple is not removed directly from the relation 
because a pointer to the tuple's predecessor in the relation 
list is not available. The alternative to marking is to 
search the relation from the beginning, maintaining a fred- 
ecessor pointer, until the canceied tupie is found. The 


relation could then be properly reiinked. 
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Markingewas wsea to avoid excessive searching of reia- 
ELONnS. When a relation is scanned on sudsequent inguifiles, 
the tuples marked for deletion are removed. oe ae wala, 
the overhead of iinear search ifs minimized. 

MacLennan introduced the cancei operator as a notational 
convenience [Ref. 14: p. 18]. This Simple construct demon- 


strates several desirable qualities of a language feature: 


* The notation is compact, yet readable. The cancel oper- 
ation removes the necessity to coce a redundant delete 


Operation. This saves space in the source fiie and in 


the resulting parse tree. 


e A potential source of error is removed. The relation 
name andtuple pattern of delete operations normally 
correspond exactly to their counterparts in a presence 
test. It is easy to missfell identifier names in the 


delete clause. 


e Cancel operations allow optimization. The use of the 
"match next" pointer reduces search time. When a delete 
operation 1S evaluated, there 1S no easy way to link 
this to searches conducted when processing the rule's 


antecedent. 


P. SEQUENTIAL BLOCKS 


The impiementation of the seguential block involves two 
mumctional characteristics: (1) the sequential evaluation 
of rules within the block, and (2) the nested scoping of 
free variables. 

Seguential evaluation is a natural consequence of the 
interpreter's design. The implementation evaluates the 
actions of a rule's conseguent in a left-to-right sequential 


order. The rules within a sequential block are processed in 
the same way. 


ao 


'1. A Single-Pass, Multi-Scepe Symbol Table 


The nested scopes of seguentiai biocks reguire an elakora- 
tion of the binding process previously described. Scoping 


is handled Ey the following stefs: 


e A block count iS maintained during = bindiage AS a 
segquentiai block is entered, this count is incremented. 
When the binding of the block is complete, the block 


count is decrenented. 


e Variables have a biock numker and an offset. As new 
free variables are encountered ina seguential block, 
their offset is determined. The variable index, 
contained in its head field, now contains two eiements: 


a block number and an offset within the biock. 


Free variables are installed in a iocal symbol takle 
as they are encountered in the binding process. To 


correctly process references to outer blocks, a nulti-scope 


symbol table is required. This symbol table is implemented 
as a two stack structure: one stack maintains the variable 
reference pointers, the other stack maintains scope 


pointers. As each variable is encountered, the symbol table 
stack 1S searched from the current stack top to the base. 
if “found, the variable is replaced by the definition 
returned. New variables are installed in the symbol table 
by pushing the variable reference on the stack. 

As a sequential block is entered, the stack top for 
the preceding scope is saved on the scope stack. When the 
binding of the sequential block is complete, the predeces- 
sor's stack top is restored from the scope stack. The scope 
stack partitions the variabie reference stack into the 
appropriate scopes. The structure is illustrated in Figure 
Delbe This symbol table structure is similar to Structimes 
used fcr conventional,- block-structured languages [Rei. 27% 
Dp 3206 
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Figure 5.8 Multi-Scope Symbol Table. 
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The dynamic evaluation of bindings reguires modificaticna to 
process the nested scopes of sequential blocks. The evaiua- 


tion function has the following additional features: 


e A global scope count. This 1S incremented when a 


sequential block beyins execution, and decremented when 


the sequential blicck is comfgleted. 


* Walking the 1links. The getbinding operation for the 
Dinding stack must now take scoping into account. gm 
this, the biock number of the variable is compared to 
the interpreter's global scope number. If these numbers 
are not the same, then the correct stack frame is 


located by traversing n iinks up the binding stack, 


where n = variable block number - current scope number. 
e Function and procedure context switches. Functions and 
procedures require new scopes. This is accomplished by 


the following seguence: 


SCOpe Save 3= CuLreent so eccve 
current _Scope := 0 
Execute the procedure or function 


current Scope :;:= Scope_Save 


This process iS Similar to static link processing in conven- 
tional block-structured languases, such as described in 
Ref. Wamp. 232-2357. 

This implementation does not require separate static 
and dynamic links. Procedures and functions execute in 
scopes separate from their points of invocation. A single 
set of links in the binding stack is sufficient to support 
multi-scope references and the calling chain of functions 


and procedures. 
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Q- SYSTEB INITIALIZATION 


The system initialization sequence is similar to that of 
the LISP prototype. The root directory is initialized with 
the names of the systems's built-in functions and  froce- 
dures. As in the LISP prototype, the directory has a self- 
referencing entry. 

An Omega initialization file is parsed and evaluated. A 
call to the sweep procedure propagates any rule activity 
resulting from these rules. This initialization provides 
the definitions for utility functions and procedures. These 
utility rules are listed in Appendix C. 

To augment the initialization file, the user may specify 
an Omega file name on the UNIX command line. The inter- 
preter will parse and evaluate these rules as part of the 
initialization process. 

Finally, the interpreter enters the read phase of its 


read-evaluate-print-sweep cycle. 
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VI. STORAGE MANAGEMENT 
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Ae THE STORAGE PROEBIED 


The kasic storage unit for Omega is the cell. These 
units are allocated dynamically, to support changing list 
StTLUCtUueS, temporary results from computations, and 
changing relation contents. Dynamic memory allocation and 
dynamic typing make relation manipulation a flexible but 
complex activity. 

The task of freeing unneeded storage yuickly became too 
complex for explicit memory reclamation in the interpreter 
design. By explicit memory reclamation, we mean that, ata 
certain section of the code, it can be determined that a 
cell is no longer needed and a call to a reclamation routine 
can be immediately made. 

Reclamation 1s complicated by memory sharing. This 
Sharing is a natural consequence of the design of Omega, and 
comes from pattern-matching and reuse of active rule 
structures. 


Consider the following rule: 
if R1(x), 7R2(x) -> R2(x)- 


When tuples are asserted to the relation R2, two possible 


Strategies may be used: 


e cory the structure. The complete tuple structures 


copied, and the ccpy added to the R2 relation. 


e Share the structure. The match operation returns a 
pointer to the tuple in R1. It is this pointer tiameaee 
pound to the variable x, and available for inclusion in 
R2. It the structure is net copied, the pointer jagger 
te R2 refers to the same structure as) thaceeneee 


0 


Consider another rule: 
ren Mee > oR (1 1, coe 


mae assertion to R2 adds a tuple generated by a list denota- 
tion in the rule -- this denotation is linked into the rule 
structure. As in the previous example, the assertion mecha- 
nism may choose to copy the structure or share the 
Ber ucture. 

Structure sharing is preferable for two reasons: space 
and time. Structure sharing obviously reduces storage 
requirements by allowing multiple references to the same 
storage areas. Of more importance in this implementation is 
a reduction in execution time. The tuples of a relation may 
be arbitrarily complex list structures. Copying these 
structures continually is an execution overhead that struc- 


ture sharing avoids. 


B. STORAGE ALLOCATION AND THE UNIX VIRTUAL ADDRESS SPACE 


The intpiementation uses tne storage allocator provided 
mathe UNIX C library. The allocation routine is nalloc. 
The reclamation routine is free. [Ref. 26] 

To understand how these routines work, a description of 
the UNIX virtual memory map is useful. An executing process 
has its virtual memory divided into three lojical areas: a 


text segment, a data segment, and a stack segment [Ref. 26]. 


The text segment contains the program code. This 
segment is normally Shared and re-entrant. The stack 
segment is used for the system's runtime stack. The stack 
begins at the highest possible virtual address, and grows 


down. The stack area is automatically extended as reguired. 
The data segment consists c£ two sections: initialized 
and uninitialized storage. The initialized storage area 


contains statically allocated storage declared in the 
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PEOyiaa l-. In this implementaticn, the binding stack, symbol 
table stack, and rule queues are implemented as arrays. 
Their storage allocation appears in the initialized storage 
area. 

The uninitialized storage area is used for dynamic 
memory allocation. Calls to malloc will extend this area. 
Calls to free will reclain, compact, and free virtual 
storage where possible. 

The maximum sizes for the stack and data segments are 
system-dependent and locally tailored to achieve desired 
performance goals. The system used for this work has the 


following limits set: 


data segment -- 6112 kbytes 
stack segment -- 512 kbytes 


This organization is illustrated in Figure 6.1 

Malloc allocates memory aligned on word boundaries. 
Structure storage reyuirements are rounded to the next four 
byte multipie based on the 32 bit word size of the VAX. The 
conseguence of word alignment is an additional space 
requirement for cells. Even though the design only speci- 
fies 8 bits for the tag field, this requirement is rounded 
tO 3 2 wbakes- A cell has 12 bytes allocated, witn 3 bytes of 


storage (25 percent) unused. 


C. IGNORING STORAGE MANAGENENT 


The interpreter was initially implemented with no 
storage management strategy. Cells were allocated when 
necessary, but no attempt was made to free excess storage. 

This policy proved to be unsatisfactory. A lengthy test 
program exceeds the system data segment limits. On one 
test, the interpreter ran for 10 minutes before exhaustiag 
its available memorv. At this point, 384,159 cells had been 
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aliocated using 4.5 Mbytes of virtual memory for cell 


Storage. 
Tt rseeossrume, but not necessarily desirable, to 
increase the data segment iimits for a process. The data 


segment limit used during testiny--6 Mbytes--should be nore 
thats Ute tere ne for this implementation. A large, 
constantiy growing process also suffers from excessive swap 
space requirements and a high page fault rate. 

These factors point out a familiar lesson: while virtual 
storage systems allow a large address space, storage manage- 
Ment is still a major consideration. These policies are 
particularly important in a muitiuser operating system such 
as UNIX, where excessively large processes can have an 


adverse impact on the user community. 


D. OMEGA-SPECIFIC STORAGE OPTIMIZATION 


Approaches were considered which reduce the storage 
requirements of the systen by focusing on specific charac- 
teristics of the implementation. Two areas for optimization 
were; (1) eliminate expression evaluation during pattern- 
Matching, and (2) reclaim ceil storage for the initial 
tuples added to relations. 

The pattern-matching routines are executed freguently as 
rules are selected for test. An active fruie structure is 
reused, so intermediate resultS must have separate storage 


allocated. Consider the following ruie: 


i= *IsManager({a, x), Position("Manager: " + x) -> 
a("is Manager") 
else if *IsManager(a, x) -> 


a("1ls not Manager"). 


In the Position inguiry, the "+" represents string concat- 


enation. To evaluate this ruie, a new tuple must be 


generated to record the results of the concatenation opera~ 
tion. This tuple is then used in the inquiry. Cells such 
as these way be generated frequently during rule testing. 

A possible optimization to this requirement is to 
restrict expressions in the antecedent or a rule to 
constraints. Strict pattern-matching is supported primarily 
by the binding stack and little additional memory is 
reguired. Ti expressions are limited to constraints, and 
constraints shifted to the end of a list of antecedent 
conditions, rule failures wili occur before the constraint 
is evaluated, Minimizing dynamic memory allocation. Tests 
conducted using this strategy Showed a decrease of cell 


allocation ranging from 10 percent to 40 percent. 


While this strategy reduces t&hemory reguirenents, the 
basic issue of stcrage reclamation is not solved. The 
restriction on turfle expressions is Significant--the 


programmer must now remember this as an exception to syntax 
and semantics. 

One possible alternative tc the above strategy is the 
use of a Separate Storage ailocator and reclamation routine 
for intermediate, temporary storage. This approach was not 
pursued because a more general solution to the _ storage 
management problem was needed. 

Certain types of relations tend to be smaii, with a 


cardinality of 1 or 0. Consider the following rule: 


hie “PUSi(a, XK, 1) => 
antes) 2 


This rule executes a Push operation by cons'ing the member x 
emto the list l. 

While multiple agents may have reguests to Push active 
at the same time, a typical situation is where Push contains 
a Single request which is serviced and promptly removed. A 


Simple strategy optimizes storage for such relations. 
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& relation list has a collection of celis which we refer 
to as tuple headers (illustrated in Figure 5.4). These 
neaders link pointers into the relation list which refer to 
the actual structures of the tuple members. While the 
pointers may change, the number or header cells is dependent 
on the tupie cardinality. This cardinality tends to remain 
fixed after it is dynamically determined. 

when the First tuple is added to a relation, the header 
cell requirements are allocated. A cancel will flag this 
tuple as deleted by marking the tag, but the tuple uae 
remain linked into the relation 1ist. A subsequent asser- 
tion may then reuse these header cells for the next tuple. 

This strategy aliows a simyfle optimization of relation 
storage requirements. Early tests of this strategy indigeame 
a potential 10 percent reducticn in celi allocation. The 
strategy postpones memory exhaustion but doesn't prevent it; 


a more general storage management poiicy is still required. 


E. REFERENCE COUNTING 


Reference counting was selected for cell reclamation. 
This technigue is described extensively in the literature. 
Our algorithms are based on the material presented in 
[Ref. 19: pp. 440-442] and [Ref. 28: pp. 383-384]. 


The implementation of reference counting required the addi- 
tion of a reference count field in the cell structure and 
some Simple management routines. 

Since 25 percent of cell storage 1S wasted, the inc#us 
Sion of a reference count field bears no additional cost. 
The reference count field is imflemented asa 16 bit signed 


integer, although a smaller field would be sufficient. 


The reference counting routines are as follows: 
® Incrref -- Increment a ceil reference count: 


ince nern p(s 
af op = Nal 
return; 
else 
parefcount := farefcount + 1 
endif 


end. 


e DecrRef -- Decrement a ceil reference count: 


Decrkefj{[p]} : 
itso Nad 
return; 
parefcount := pa@refcount —- 1 
1£ pa@refcount <= 0 
1£ ~a is a string cell 
free string storage 
else if pd is a iist ceil 
DecrRef[ padhead ] 
DecrRef{ patail ] 
endif 
free p 
endiz 


end DecrRef£ 


When a cell for an atom 1S created, its reference count 
is initialized to zero. Reference counts are aitered when 
pointer references’ change. This occurs in the following 


routines: 
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e NewCell -- Create a new list cell. fhe algorireine 


NewCeil; x, yj: 
p := mallocf{ celisize] 
parefcount := 0 
pdhead := x 
pdtail := y 
Inerreiiee) 
Incrketi ys 
return p 

end NewCelil 


e SetHead -- Change the heaa fointer for a cell. This is 


the rplaca function Of elise: 


SetHeac[ x, y]: 
THCY Refi ys); 
DecrRef; xdhead j; 
xdhead 3:= 

end SetHead 


e SetTail -- Change the tail fointer for a cell. Thijsiae 
Eplacd £urction Of vuirse: 


Setladelj xy Vas 
IncrRef{ y } 
DecrRef[{ xatail] 
x@tail :=y 

end SetTail 


Reference Counts also need to reflect the references of 
a recursive implementation. To illustrate this pom 
consider the following interpreter routine to inplement 


MUltd pl icat2on: 
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Mal cee y |) 2s 
incrReff{ x } 
IncrRed[ y ] 
temp := Makint[xdhead * ydheaa ] 
DecrRef[ x } 
Decrkefj y } 
return temp 


end Mult. 


Berore its invocation, the arguments to Mult have been 
recursively evaluated. If these parameters involved expres- 
Sions, then either parameter may be an intermediate result. 
The IncrRef operations reflect the Mult routine's references 
via its formal parameters. After completion of the multipli- 
cation, the references are decremented with DecrRef£, which 
will free intermediate results that are no longer required. 

Reference counts must remain consistent, so an analysis 
of local references throughout the interpreter was required. 
A point of interest is the binding stack: the bind operation 
must increment a cell's reference count while the unbind 
Operation must decrement the reference count. The determi- 
nation of these specific reference counting points proved to 
be a tedious process, although still more tractable than 
explicit reclamation. 


Reference counting offers the following advantages: 


seo implicity. The data structures and algorithms are 


Supported by the existing recursive interpreter design. 


e Immediate reclamation. Unneeded storage is reclaimed 
immediately. 
e Uniform computational requirements. The overhead of 


Storage reclamation is spread out over the execution 


time of the interpreter. 


NOT 


A major limitaticn of reference counting is the diffi- 
culty in reclaiming cyclic structiupec: The design of Omega 
prevents this problen. Only “pure" lists are used and 
rplacx oferations are not defined. 

Reference counting places a computationai burden-- 
incrementing reference counts--at a sensitive point: memory 
allocation. The execution penaities associated with refer- 


ence counting are examineil in the next chapter. 


Fe. GARBAGE COLLECTION 


Garkage collection was not selected as a storage manage- 
ment strategy because of the ccmplexity of implementaticn. 
The malloc and free routines offer a predefined storage 
allocation systea, while a garbage collection systen 
requires an explicit design of these components. 

The development of a garkage collector would be an 
interestiny extension to the current design. Some of the 


considerations for a mrark-and-sweep garbage collector are: 


e Structure access is required for the mark phase. This 


phase needs to access the following interpreter 


structures: 
1. The object table. 
2- The active rule table. 


3. Rules under evaluation by the console ccmmand 


processor. 


Gu. Rules under evaluation by the file ccmmang 


processor. 


5. Intermediate results generated duming rule 


evaluation. 
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Accessing intermediate results is complicated by the 
present recursive implementation. A possible solution 
is to maintain a stack specifically for referencing 


these structures during a mark phase. 


e Cells reguire a mark bit. The current cell structure 
provides an 8 bit tag. Bits Ow tomoudgn S.arewsed for 
the tag value, bit 7 is used as a ilag on certain 
structures. Bit 6 remains available for marking 


purposes. 


e Complete storage access is reguired for the sweep phase. 


This immediate access implies that the memory allocator 


must be managed by the interpreter. To maintain a 
reasonable virtual memory image, this allocator tust 
Obtain and release memory on paye boundaries, using 


compaction whenever possible. 


Ge. REDUCING CELL STORAGE 


The current 12 byte reyuirement for cell storage is 
large. Since the cell structure is based on the LISP model, 
humerous LISP techniques may ce used to reduce this 
requirement. 

LISP structures have fewer distinct cell types. Instead 
of encoding tay information directly, Storage for cells of 
different types are often allocated from noncontiguous, 
separate sections of memory [Ref. 29]. In this way, the 
address range of a pointer frovides the necessary type 
information. 

List linearization techniques are another way to reduce 
storage requirements. These technigues attempt to maintain 
Satis, normally linked via their tail pointers, in contig- 


uous storage. This allows a reduced tail field size, witha 


109 


field containing a cell offset to the next cell angieme 
structure instead of a full pointer. An escape mechanism 
allows full pointer access where necessary [kef. 30: Pp. 
2667]. 

The above techniques are mertioned as potential improve- 
ments in the current allocation scheme. These techniques, 
like garbage collection, require more explicit control of 
storage allocation than is offered by the current design. 

A potential storage savings can be obtained with the 
current tagged cell structure [Ty embedding the tag in the 
tail field. This 1S a simple modification that requires 
masking the tail field value to obtain the tag or tail 
pointer. Tf a reference ccunting field is not used 
(assuming garbage collection instead) this technigue 
reduces the current cell requirement to 8 bytes, a 33 
percent reduction. Using this encoding scheme, the tail 


pointer 1s restricted to a 24 bit range. 


VII. PERFORMANCE EVALUATION 
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A. METHODOLOGY 


A progressive series of programs were developed to test 
features as they were implemented. These programs assisted 
in determining the interpreter's reliability and execution 
characteristics. Execution profiles and comparative bench- 
marks were used to evaluate behavior and performance. 

In this implementation, performance was subordinate to a 
clear, workable design. Performance optimization efforts 
were started only after the design and implementation of a 
series of features were complete, with all test programs 


successfully executing. 
1. Execution Profiling 


The gprof call graph execution profiler [Ref. 26] 
waS an important tool for evaluating weak points in the 
performance of the interpreter. Execution profiles pointed 
out some immediate inefficiencies in the implementation that 
could be easily remedied. 

A simple example is the tag function. tnogeaa liye, a 
function was used to extract the tag value from a cell. The 
rationale behind this implementation was information hiding: 
the details of the cell structure were accessible to only a 
few handling routines. 

Execution profiles on fattern-matching showed this 
implementation to be costly: the interpreter spent over 10 
percent of its execution time extracting tags. To solve 
this problen, the function was rewritten as aC macro 
Meets 22: p. 86]. The VAX instructions generated by the 


alternative implementations are shown in Figure 7.1. The 


macro implementation results in a Savings OE ~ 


instructions--a substantial improvement given the high 
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Function Inplementation 





C statements VAX i1nstrucuoens 
x = tag(p); pushl -8 (fp) 
calls _tag 
novl r0,-4 (fp) 
ta 
ce 1Ph 
cvtbl ¥*4 (ap) ,rQ 
return (p=>tag)%: ret | 
Macro Implementation | 
C statements VAX instructions | 
# define tag (x) (x->tag) 
| x = tag(p); cvtbl *-8 (fp) ,-4 (fp) | 
_ 
Figure 7.1 Code generation for TAG function. 


frequency of tag extraction during interpretation. 


Replacing procedural implementations with macros is 


not a panacea. Macro implementation has at least two 
disadvantages: 

e Debugging is more difficult. Macros are textually 

expanded by a preprocessor before compilation. The 


errors that occur are unusual, do not correspond well 


with source code, and may produce unexpected effects. 


e Profiling information “155 eon An execution profile 
pointed out the expense of the tag function. Once coded 
as a macro, the cost of this code sequence is absorbed 


in the routines where the macro is expanded. 


2. Benchmarking 


In this chapter we present a coliection of Simple 
benchmark programs. The performance of the Omeya inter- 
preter is compared to interpreted Franz LISP, compiled Franz 
meoP, and the C-Prolog interpreter. tc Gar rT OLog 1nt erm 
preter is a VAX Prolog implementation descended from the 
DECsystem-10/20 Prolog system [Ref. 31 and 32}. These 
systems are all written in C. 

These benchmarks are net intended as an evaluation 
Of C—-Prolog or Franz LISP, and no effort has been made to 
write efficient Prolog or LISP. Because these systems are 
well-engineered and efficient in what they do, we present 
these benchmarks as an indication of the current proyress o£ 
our implementation. The source code for the benchmarks is 
included in Appendix D. 

Timing information was cbtained through calls to the 
date function of the UNIX command shell [Ref. 26]. The 


following Omega rule demonstrates this technigue: 


1£ *qTest(a) -> { 
System {"date"} ; 
Osortf{iotak[1, 150 }}; 
systen {"date"} ; 
ae 


The date function returns the current system time to the 
nearest second. The test systems all possessed a function 
Similar to the System procedure shown above, and the over- 
head of executing such a system call should be consistent 
between interpreters. The timing granularity of one second 
reguired establishing benchmarks of sufficient duraticn to 


provide meaningful ccmparisons. 


SB. Onega Statisimics 


Besides benchmark and profiling measurements, addi- 
tional information was collected to begin a characterization 


of Omega program behavior. This information included: 
e Data type frequencies. 
e Hash collisions in the object table. 


e Relation characteristics: relation cardinality and tuple 


cardinality. 


The last two areas are dynamic characteristics which change 
as rules fire and alter the database. These measurements 
were taken using a Sampling technique: object table meas- 


urements were made immediately after each rule evaluation. 


Be” LES f RESULTS 


Benchmark programs were tested using two different 


versions of the interpreter. The versions were: 
e The standard interpreter without reference counting. 


e A version compiled with the gprof profile option and 


containing object table and cell measurement routines. 


The overhead of measurement and profiling necessitated the 
separate compilations. 

The execution profiles produced by gprof are extensive. 
These are summarized and included in profile summary tables, 
with the profiling information for the five most expensive 
(in execution time) routines shown. The percentages given 
in these profile summaries are taken directly from the 
profile reports, and reflect the large overhead of the 
profiler. The profiling routines typically consumed about 


50 percent of the total execution time. Thus, if ee 


execution percentage. for a routine iS shown to be 5 percent, 
its relative impact is approximately 10 percent in unpro- 


filed execution. 


i-eoeratthern—-Natching Lest 


This benchmark asserts a common tuple in two rela- 
tions, followed by 1000 disjoint assertions to’ each. A 
pattern-match search finds the common tuple. The search 
requires more than 2 x 106 pattern-match tests, a worst-case 
performance. 

The Prolog version iS Similar, with assertions made 
to the Prolog rule base. Prolog searches the rule base from 
Zop to botton. The common clauses are asserted and subseq- 
uent clauses placed before these uSing the asserta predicate 
fener. 21; p. 105}. 

We include a LISP implementation of a nested loops 
search, although this isa simplification of the pattern- 
matching process of Omega and Prolog. Only a compiled LISP 
version was tested because an interpreted version is at an 
unfair disadvantage when competing with the direct implemen- 
tations of this process. 

The timing results for this benchmark are shown in 
Table Ii. A Summary of the Omega execution profile is Snown 
eo table Iil, and type information is shown in Table IV. 


Relation characteristics are not shown for this test. 


wee Pactorial Functions 


we ce es ee ee eee SS ee me eS 


This benchmark exercises the applicative component 
of the interpreter. AeeGecUrsivVe = lactorial function is 
executed 500 times, Witue Cvenwrcall) computing Fact{ 15}. 
Larger factorials are not used because both Franz LISP and 
Omega experience integer overflcw in their computation. 

Timing results are shown in Table V, and an Omega 


execution profile summary in Tabie VI. Table VII shows the 


TABLE II 


Execution Times: Pattern-matching 


Systen Execution Time (secs) 
Omega 202 
Prolog 102 
Lise 
Interpreted N/A 
Compiled 230 


(es ees ge Gees neces Some Gey SS | 
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TABLE IIil 


Execution Profile Summary: Pattern-matching 


% Execution 


No. 
Time Gaels Name Descr 
3025 2021016 uni fy patt erie a 
TUE 1010985 equ ist equality test 
ee 5035 match s linear list Search 
4.4 100400 FreeBind reset frame bindings 
O39 70019 eval evaluation function 


Omega type distributicn for this benchmark, and Table VIII 


shows the relation characteris ti¢e- 


3. A Prime Number Sieve 
The third benchmark is a prime number generation 
progran. The benchmarks use a sieve algorithm to remove 
prime number multiples from a list of numbers. This is an 


interesting benchmark for Omega in that the sieve is driven 


by rules, but the major computation--removing multiples--is 


TABLE iV 


Data Type Frequencies: Pattern-matching 


Type Freguency pmoOre LOtad 


=_—_——_ —_ — EP Pe ee ee ee ee —> ee ee ee ee oe 


p ! 2 
Data List 8 
Atoms 
Integer 2 
SE 1m 1 
Boolean 3 
Cbhyject 
Variable 


EN ee | 





tH 
bh 
Wn 
ct 
WH 
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TABLE V | 
Execution Times: Factorial | 

Systen Execution Time (secs) | 

| 

| 

| 

i 

| 

J 


bro 


ened Z 
Prolog a 
Interpreted 1 


Compiled 


cs 


performed by the applicative component. The Prolog version 
is based on an example given in [Ref. 21: p. 157]. 

The timing results for this benchmark are shown in 
Table IX. These times are based on a sieve list of 350 inte- 
gers. A summary of the Omega execution profile is given in 
Table X, data type distributions are given in Table XI, and 


mratiOn characteristics in Table XII. 


Pn 
| TABLE VI 
| 


Execution Profile Summary: Factorial 





| nn, 


% Execution No. 
| Time Cadeus Name Descr 
14.8 155457 eval evaluation function 
ae S205 0 malloc memory allocation 
BS 24001 binop binary operation 
Zou 30346 newcell create a new cell 
| eo SOF fp eval tuple/args 


a 


| 
| 


TABLE VWI 


Data Type Frequencies: Factorial 


Type Frequency % Of Total 


> a —_— ee ae ee 


Atoms 
Integer 1 
Ser dG 
Boolean 
Cbhject 
Variable 


[ee 


Pp : Z 
Data List 9 
5 

1 


tC i 
bh: | 
wm | 
ct | 
" 
er 


4. Quicksort 


This benchmark exercises the Omega procedure call 
and pattern-matching mechanisms. The Quicksort splits 
lists, recursively sorts the sublists, and combines tne 
results. The Prolog version is taken from the example given 
an [ Ret. 213 2p. 887 ye 
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TABLE VWiit 


Omega Relation Characteristics: Factorial 


Sample Frequency: 2078 


| Characteristic Mean Std Dev Mode 
Relation _. 1.0 0.0 1.0 
| cardinality 

Tuple | : 2.0 Oren Ze 0 

cardinality 

De cs aoe Collisions: 

Collision List Length Frequency 
| 1 43126 


TABLE ix 


Execution Times: The Sieve 


? ; 
| 


Execution Time (secs) 


1S eS 
Interpreted 3 
Compiled 


O 
5B 
ay 
pu 
ot 
ve) 
a eee > Gece Ge ee Go ee ee os 


r 


The timing resultS are shown in Table XIII. MThese 
times are based on executing an ascending sort ona list of 
150 aintegers initially arranged in descending order (an 
O(n*) undertaking for Quicksort). An execution profile 
summary iS given in Table XIV, and Table XV contains the 
data type frequencies. The relation characteristics of the 


benchmark are shown in Table XVI. 





TABLE X 


Execution Profile Summary: The Sieve 





| Variable 


>. Ae Simulation Feogran 


Sa a A a ee Ee ee 


coe ee ee 


| 
| 
| &% Execution No. | 
Tine Calis Name DeSCIr 
1367 118635 eval evaluation function 
u. 16462 tupl eval tuple/args | 
4.0 29425 malloc memory allocation 
Zo 28169 newcell create new cell 
Za) 12348 iInarl apply £n to args 
| 
| 
a a J 
TABLE XI | 
| Data Type Frequencies: The Sieve 
| Type Frequency % of Total | 
Lists | 
Op List 1990 7 
| Data List 20359 2 72 | 
Atoms 
Integer 20.6 Vz | 
String 1146 4 
Boolean 423 z | 
Cbject 232 1 
761 3 


This example is a Monte Carlo Simulation of a three 
node message Switching network. It iS a more complex 
program than tne preceding benchmarks, and the interpreter 
exhibits a wider range of activities. The source code for 


the Simulation rules is listed in Appendix E. 
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| 

| TABLE X11 | 
| Omega Relation Characteristics: The Sieve | 
| Sample Freguency: 149 | 
Characteristic Mean Std Dev Mode 
Relation _. le oF 0 10 | 
cardinality | 

| Turie | ; Ze 0a5 aen0) | 
Covecue Mac hit y. 
Bees a Re Collisions: 
Collision List Length Frequency | 

1 2694 | 


Ale EE SS Se ee ee ee ee 
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TABLE XITiL 


Execution Times: Quicksort 


System Execution Time (secs) 
Omega 142 
Prolog i 
Se 
cer Deas B 1 
Compiled 40 


mein nia a ee 


Comparative benchmarks were not written for this 
problem, and timing comparisons are not shown. The execu- 
tion profile for the simulation is given in Table XVII, data 
type frequencies are shown in Table XVIII, and relation 


Statistics are shown in Table XIX. 
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| TABLE X&1V 


Execution Profile Summary: Quicksort 


| 
| % Execution 


NO. 
| Tine Cadaiks Name DeScr 
1a? TAS 6 eval evaluation function 
Sn 2 ose) unify pattern-matching 
Za 15 1009 malloc tae allocation 
Zeb OTT > tupl eval Up Cea 
Za 143777 newcell create new cell 


| i Clini Go ey 





TABLE XV 


Data Type Frequencies: Quicksort 


| Type Frequency ~ Of tetal 
Lists | 
Op List 1753 
Data List 121627 
Atoms 
Integer 170 
Strang 6820 
Boolean Vela 
Object 533 
Variable 808 


Mire ey EE gees ee 





C. IMPACT OF REFERENCE COUNTING 


The timing information presented previously was’ taken 
without reference counting. A separate version of the 
interpreter was compiled with the reference counting 
routines included, and separate measurements taken. The 
impact of reference counting on execution speed is shown in 
Table XX. A Summary of the Quicksort benchmark, with refer- 


ence counting implemented, is shown in Table XXxXI. 


eee 


TABLE XVI | 
Omega Relation Characteristics: Quicksort | 
Sample Freguency: 35704 | 
| Characteristic Mean Std Dev Mode 
| Relation _. 1.0 Oin0 1.0 
cardinality 
| Tuple | 4.9 O.7 S)A, 
Cardinality 
paler. faples Collisions: 
lision List Length Frequency 
| 1 785578 | 
| Z 2 ! 


| 
| 
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| TABLE XVII 


Execution Profile Summary: Simulation 





% Execution No. 
| Time Calls Name DeSscr 
9.4 211360 eval evaluation function 
ie 3 62126 unify pattern-matching 
Zo 63782 malloc memory allocation 
Dea | 1221 write system i/o 
eG 321220 Lookup hash table lookup 


EE 
i 
a 


D. DISCUSSION OF RESULTS 


1. Performance Bottlenecks 


eps EE EM ee ee a > see Se ee ee 


The measurements presented in the preceding sections 


provide some insight into the effectiveness of the present 
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TABLE XVIII | 
| Data Type Frequencies: Simulation | 
Type Frequency %@ of Total | 
Lists | i 
Op list 6125 11 | 

Data List 26053 47 
Atoms 
Integer 2147 4 i 

| String 6340 11 
Boolean 10124 18 
Object 2390 4 | 
| Variable 2290 4 | 
a 


| TABLE XIX 


Omega Relation Characteristics: Simulation 


. 


Sample Freguency: 9972 


ee een 


Characteristic Mean Std Dev Mode 

Relation _. Dian! as! 1.0 
cardinality 

Tuple Las O.7 2 


cardinality 


OF Geog ae Collisions: 
Collision List Length Frequency 


eT Sn ge: Ge gai, GN ee 


1 404828 

2 180974 

3 26152 

4 4552 

5 27 On 

6 11 
lo ee ———— eee 
implementation. The execution speeds for the Omega bench- 


Macks are consistently slower than C-Prolog and Franz LISP. 
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TABLE XX 


{ 

; . ; | 

Reference Counting and Execution Times | 
{ 

| 

| 

| 

| 

| 


Benchmark w/o Ref Counts w Ref Counts &%incr 
| Pattern 22 2a3 5 
match 
om Factorial 23 30 30 
| Sieve 19 25 32 
81 27 


| Quicksort 142 1 





TABLE XXI | 
Profile of Quicksort with Reference Counting | 
% Execution No. | 
Time Cadeis Name Descr f 
is TEA TSIEN eval evaluation function | 
: 216385 une ty . Pee ce una Caen 

Bel 421556 Decrret decrement ref count 
S63 541624 incrRef increment ref count | 
2.4 151009 nalloc memory allocation | 


This performance is shown in both applicative expression and 
rule evaluation. 

The central evaluation function, eval, consumes the 
Majority of execution time. This 1S not surprising given 
the present recursive implementation: eval is called 
directly or indirectly in most cperations. Embedded in eval 
are accesses of the binding stack for atom evaluation in 
tuples and argument lists. 

The high frequency of calls to eval suggest its 


design aS a potential point for optimization. This 
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optimization may include a reduction of unnecessary Leauge 
Sive calls to eval. When evaluating interiox nodes ofa 
rule tree, the sons of a node are always passed to eval, 
which will decode the tag and call the appropriate subordi- 
nate routine. If the required subordinate routine is known 
at the parent node, the intermediate call to eval may be 
omitted. 

Another alternative is to replace the recurSive eval 
with an iterative version. This requires the nanagement of 
an explicit operand stack, and involves a major redesign 
CGLOrt. The management of an operand stack would, however, 
solve an implementation problem for garbage collection 
discussed in the previous chapter. 

The pattern-matching routine becomes Significant in 
extended rule processing, as shown by the Quicksort and 
network Simulation tests. We necte similarities between eval 


and the pattern-matching routine unify: 
e Both routines are heavily exercised. 


e Both routines access the bindiny stack when evaluating 


free ValLiables-. 
e Both routines are recirsive. 


The recursive aigorithm for pattern-matching is Simple and 
eiegant. An iterative version would be more complex, but 
may provide a performance gain. 

A final area for performance improvement is storage 
management. The storage allocation routine, malloc, and 
routines that call it, such as newcell, consistently rank 
high in the execution profiles. Our implementation of 
reference counting for storage reclamation proved to be 
expenSive, with a 30 percent increase in execution time for 
extended tests. These results make garbage collection 
appear to be a desirable alternative. Hardware support for 


reference counting could also provide a solution. 
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Pee oe har On ta tiStves 


The statistical information gathered on relations 


provides some evidence to support previous conjectures: 


e Small relations are commonplace. The mode for relation 
cardinality was 1.0 in every test. These statistics 
will vary depending on the application, and generaliza- 
tions can't yet be made tased on the limited tests 


conducted. 


e Object identifiers hash well. The object table colli- 
Sion results indicate an even distribution of hash 
values. Collisicns in the object table siow down rela- 
tion list lookup, an important part of the synchronous 
procedure call. Only in the Simulation test did hash 
table lookups begin to become significant in the execu- 
tion profiles. This coincides with the increased number 
of objects generated and an increased Goris 1on 


frequency in the object table. 
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VIII. OBSERVATIONS, RECOMMENDATIONS, AND CONCLUSIONS 


A. OBSERVATIONS ON CHEGA 
1. Programming Experience 


Our experience with Omega programming is reflected 
in the rules listed in Appendices C-E. We believe these 
examples demonstrate a variety of applications which have 
Simple solutions in Omeya rules. 

An important body of rules are the system utilities 
listed in Appendix C. Included are relation copying utilae 
ties, an extension to the system pretty printer, anda help 
fac 7 ity. The last appiicaticn shows a simple use of the 
System procedure call to list help files at the user's 
terminal. This technique could be extended to use the Omega 
interpreter as a rule-based driver for the UNIX command 
Sheil. 

The longest and most significant application is the 
Simulation model listed in Appendix E and profiled in the 
previous chapter. We include this example as an event- 
driven, sState-transition problem which is readily expressed 


as rules of the form: 


1E Clock (El), “Event (2 1,7.e). = 


PLOCESSEVeRU le}. 


2. Omega and Prolog 


The benchmarking examples of the previous chapter 
presented rules in Prolog and Omega that are similar in 
form. Both these languages use pattern-directed invocation 


for rule selection, and both languages are intended for 
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general programming applications. Despite similarities, 
these languages have fundamental differences. 

Omega uses forward inference, Prolog uses backward 
inference; Omega programmers and Prolog programmers think 
in different directicns. To design an Omega rule, one uses 
the train of thougnt: "Given the current state of the 
system, generate the next state." A Prolog rule is designed 
with the thought: "To prove this goal, it is necessary to 
prove these subgoals." Prolog relies on a theorem-proving 
approach, Omega on a data-driven approach. 

These opposite control strategies are reflected in 


different implementation technigues: 


e Prolog recursively evaluates its rules from a goal 
Stack. This oe often allows intermediate storage 
allocation from stack structures. This method of allo- 
cation and reclamation 1S simpler than the heap alioca- 
tion used by Omega and LISBP, and results in a faster 
cons operation [Ref. 32: p.j 114}. This performance is 
refiected in the Quicksort benchmark of the previous 


Chapter. 


e Theorem proving requires backtracking. Prolog selects 
rules from its rule base to prove subgoais. If multiple 
rules for a subgoal are present, they will be selected 
and tested until the subgoal is proven or all possible 
rules fail. Backtracking kLetween rules requires a nore 
general pattern-matching techniygue in Prolog than Omega. 
in Prolog, variables may re bound to variables. In 
Omega, a rule fires or it doesn't--there is no require- 
ment for backtracking between rules, and variables are 


bound only to objects and values in the database. 


Programming problems may be solved by either forward 


or backward inference. To illustrate this point, we use the 
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Missionaries and cannibals protlem [Ref. 33: pp. 51 laa 
Simple state-space search exanfgle. The Omega and Prolog 
rules for this problem are listed in Appendix D. 

In the missionaries and cannibals problem, a simpli- 


fied description of the Omega rules is: 


if *State(x, path), GoaiState[ x] -> 
Displayn {path} 

else 1f *State(x,path), IslegalState[ x], 
=menber[ x, path] e=7 
GenerateNewStates {x,[ x: path }} 

else if *State(x,path) ->. 


Given a starting state, the Omega rules will generate all 
possible new states that may le reached from that state. 
This process continues until all combinations of legal 
states have been tested. No backtracking iS required in 
these rules--successful states continue to fire, and unsuc- 
cessful states are removed from the computation. We main- 
tain alist of previous states in the variable path to 
prevent cycles. 

A simplified version of the Prolog rules’ for this 


problem is: 


goalS tate (x ,Path) 3 = 
finalState (X), 
print (Path). 

goalState (X,Patn).:. 
not member (X,Path), 
legalState (X), 
possibleNextState (X,Y), 
goaistate (Y7{ xX) Pawn 


In the Prolog version, the predicate possibleNextState wiil 
bind the variable Y to a new state that can be reached fron 


Xs In its attempt tc "prove" the starting goal state; eas 
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possikle state combinations wiil be generated fy back- 
tracking on possibleNextState. We observe Prolog exploring 
new states through backtracking where Omega relies cn the 
generaticn of new states in the database. 

Certain classes of problems lend themselves well to 
the natural recursion inherent in Prolog. The Quicksort 
rules of Appendix D are a model of brevity and clarity. We 
suggest that event-driven or data-driven applications, such 
as the simulation example of Appendix E, are better 
described through Omega. Omega was developed as a high- 
level language for programming environment description and 
implementation. This family of applications are represented 


more naturally through forward inference descriptions. 
3. Zhe Production Rule as a Programming Paradign 


Both Omega and Prolog use the production rule as the 


programming paradign. How eaSy is it to program with 
production rules? We consider this to be an application- 
dependent guality. A problem can be effectively described 


with production rules if the following characteristics 


apply: 


e The problem can be decomposed into a set of snall, 
cause/effect subproblems. Each subproblem is described 


by a single rule or small set of rules. 


e The subproblems are independent, and reyuire nmininal 


CONMmmuntGaction between rules. 


The independence of rules allows the programmer to 


add or remove rules without concern for the impact of these 


Changes on other rules in the active rule list. In our 
current design, the rule denctation is the unit of rule 
organization. Thus, a goal for a manageable rule structure 


is independence of rule denotation sets. 
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A significant limitaticn of most productiongeee 
systems is a lack of meaningful semantic composition, the 
inability to compose a complex action from a collection of 


previously defined simpler acticns. Rosenchein writes: 


{In production systensj] tests. and transformations are 
sophisticated and are designed to implement constructs 
LOUnG an) Vaerous a eee eae However, there is gener. 
ally no way to Symbolize comfosition ot operations ieee 
transparen ee Complicated tests and actions have to 
be Simulated y groups of cules whose coordination is 
not symbolized in the program or graced with a mnemonic 
name. The more ccmplicated the tests and actions eee 
more severe the coordination froblems. This 1S tyYpiigaen 
of programs written at one level of abstraction, no 
matter how eOpHt erica ree the primitive operations. 
[Ret. 34: pissy 


Omega provides some pctential solutions to this 
problem. The object-oriented approach of the language 
allows the partitioning of related data and rules through 
directories and classes. This organization of the name 
space provides the first step ina hierarchical composition 
of rule activity. 

The second step is the procedure call mechanisn. 
This mechanism serves as an invccation trigger for a coilec- 
tion of rules, with a method of integrating the outcome from 
their actions into more complex expressions. The utility of 
this mechanism is indicated by its widespread use in the 
examples presented in this thesis. 

Although our programming examples are dependent on 
the procedure call, we note fotential problems with the 


mechanisn: 


e The actions associated with a procedure call may not be 
obvious. The procedure call asserts a tuple to a given 
relation, and extracts the response from its mailbox. 
Multiple rule denotations may use the procedure's rela- 
tion, and fire as a result of the procedure assertion; 


the possibilities for subtle side effects are 


eZ 


Seb od eed er The final effect of a procedure call can 
only be determined from an analysis of ali rules associ- 
ated with the procedure's relation name (as defined in 


its directory). 


e The procedure mechanism does not enforce parameter 
checks. The tuple asserted in a procedure call is anal- 
ogous to the actual parameters of a conventional proce- 
dure call. In Omega, there is no parameter counting or 


type checking. Consider the following rule: 
it wea, xX) -> displayn {x}. 


If the user mistakenly enters "R(100)," the assertion 
will be made but the rule will not fire because of a 
pattern-matching failure. fhe procedure call "R{100, 
2003" will fail for the same reason. In both of these 


Situations, no error indication will be given. 


There are programming technigues that correct the 


last problem. If we code the rule as: 
iced) —2 « -« 


the head/tail list specification will match against any 
tuple. The rule designer may then code explicit type and 
parameter count checkS with an appropriate response to 
errors. We use this technigue in the utility rules 
contained in Appendix C. 

A declarative mechanism may also be used to specify 
the expected tuple size for a given relation. Any devia- 
tions would trigger an error response. 
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B. RECOMMENDED AREAS FOR ADDITIONAL STUDY 
1. Extensions to the Language 


Our programming and implementation experience with 
Omega have suggested three additional extensions to the 
language: (1) a syntactic distinction for free variables, 
(2) a universal quantifier, and (3) named rules. 

In our current implementation, the distinction 
between free and bound variables is made when rules are 
activated: if defined in the class/directory structure, the 
variable is bound; if not defined, it is considered free. 

This strategy iS a fotential source of error. 
Suppose we wish to define a constant, and use the following 


definition; 
Define {Root, "a", 100}. 


The selection of the variable name a will conflict with the 
majority of our rule denotations, where this variable is 
consistentlv used to represent a mailbox relation. The 


activation and test of the follcwing rule: 
1f *fT(a, x) -> a(2 * Xx). 


will result in a type clash error. Tnese errors are subtle, 
and require the programmer tc remember which names are 
previously defined in a given environment. To solve this 
problen, free variables should be syntactically distin- 


guished. Thus, the preceding rule may be written: 
lf *7 (Gay &x) —-> Ga Ss see 


Previous definitions cannot adversely affect this rule. 
C-Prolog uses a similar convention: free variable names 


begin with upper case letters, bound variable names begin 
with lower case letters. 
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In Chapter 2, we emphasized the point that a rela- 
mPon 8 anguiry 1s existentially .uantified. Consider the 


following rule: 


Pie Commne trl, 62) 78 Wises ar 2.x ie > 
GZ {x } 
else if *CopyRel(ri, r2) ->. 


This rule implements a relation copying utility. The 
programmer's intent for this rule is that all tuples in rl 
should be asserted to relation f2. Existential quant 1£1ca— 
tion will select a single tuple on each firing cycle for the 
rule. Note that the absence test on relation r2 1s required 
to ensure termination. 

A possible alternative is to provide universal quan- 
tification for tuple selection. With this mechanism, the 


copy rule could be written: 
Mee OpyRel(ni, r2), $ri{(x) -—> r2(x). 


The "$" symbol 1s used to represent universal quantifica- 
~ion. The action of the quantifier is "for all tuples x in 
relation ri, assert x to relation r2." A universal guanti- 


fier offers the following advantages: 


e The programmer's intentions are more clearly expressed. 
There 1S a Similarity between universal guantification 


and the mapcar function of LISP. 


e Performance may be enhanced. A universal quantifier 
allows optimization by completing the actions of the 
rule in one rule cycle. The costs of multiple rule 
selection and testing, Shown in the profiles of the 


unify procedure in the preceding chapter, may be high. 


It 1s recognized that the existential guantification 


of the present design is sufficient to accomplish the 


3 5 


intended function of the CopyRel rules and similar applica- 
E1LOnS. The advantages of universal yguantification must be 
weighed against the added complexity to the language. 

It would be useful to be able to reference rules by 
name. The rule forms the basic computational unit in the 
language, yet may nct be referenced explicitly; the only 
named reference for a rule is its source rule denotation. 
If the denotation is large, its name is not a selective 
description. If a single rule is to be manipuiated, perhaps 
by a structure editor, tke entire denotation must be 
accessed. A Similar problem iS experienced with activating 


and deactivating rule denotations. 


2. Extensions to the Presen 


Our present implementation includes the majority of 
Omega language features descrited in [{Ref. 14}. Several 
possible extensions to the present implementation are of 
interest. 

The class mechanism described in Chapters II and iV 
is not currently implemented. MThe present system provides a 
Sinyle directory, root, frequently referenced in our exan- 
ples. The class and directcry structures, with rules 
indexed on relation objects, provide the inheritance mecha- 
nism for the language. The implementation of classes as 
pDinding lookup paths will allow a more thorough exploration 
of the object-oriented nature of Omega thah has pean 
provided in this work. 

Both the LISP prototype and the current prototype 
use a simple linked-list relation structure. There are two 


alternate representations that are of immediate interest: 


e Hashed indexing of relation lists. Relations lists are 


currently selected via hashed access of the object 


tabie. A performance-enhancing extension to this 
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technigue is to provide a nashed index structure for 
tuples within a relation, possibly uSing a user- 
specified key or arbitrarily using the first tufle 
member as a_ key. An indexed relation structure would 
have little impact on most of the benchmarks of the 
preceding chapter (except the pattern-matching test) 
because of the small relation sizes. A substantial 
performance improvement for inguiries on larger _ rela- 


tions may be realized. 


e A relational DBMS implementation of relations. The 
current deSign can be extended to include a query and 
response translation interface with a concurrently 
executing DBMS. The interface could be organized around 
object identifier recognition, as system objects are 
currently handled. The tag field of DBMS-supported 
objects could be assigned a unigue value to route these 
objects to the DBMS interface instead of the normal 


relation management routines. 


Control strategies for rule selection and test 
remain an open subject in this work. OUb two> reve ll trig— 
gering strategy, discussed in Chapter V, was selected as a 
compromise implementation taat provides a reasonable level 
of rule selection preciSion under a programmer's control. 
Full indexing of rules--triggering on all the relations in 
the rule antecedent--was not attempted. The performance of 
full indexing compared to two-level triggering 1S a poten- 
tial point for additional study. 

The control strategy of Omega, iPrke Prolog, 1s 
"hard-wired" into the interpreter design. The designs of 
several other rule-based systems have taken a more flexible 
approach: meta-rules dictate control strategies [Ref. 35]. 
The idea of integrating rule-based control strategies into 
Omega would be an interesting extension to the language and 


its interpretation. 


i? 


The space considerations of Chapter VI, as well as 
the execution statistics of Chapter VII, indicate thata 
garbage coilection scheme may preferable to rererence 
counting. The implementation of an efficient compacting 
garbage collector can provide Significant performance 
improvements. 

A useful extension to our implementation would bea 
flexible debugger. We currently use a trace facility that 
provides a display of rule execution. While this facility 
is useful, the information provided is not specific enough. 


The following debugging features would be helpful: 


e Specification of trace and break points by relation 
name. When a tuple is added or removed from a relation, 
the debugger may be invoked and the bindings of vari- 


ables available for examination. 


e Specification of trace and break points for specific 
rules. This facility 1S similar to the preceding one, 
but only certain rules are monitored. Note that the 
lack of names for individual rules makes this feature 


difficult to implement. 


e Debugger invocation on error conditions. AS in the ee 
prototype, error conditions result in an error message 
and a return to the interpreter's top level. The imple- 
mentation of a dekugger would allow a more sophisticated 


response. 


Our present method for rule creation and modifica- 
tion should be extended. Currently, the following steps are 


used to create rules: 


e Command rules are entered into a file using a standard 
text editor. The vi procedure call is provided in Omega 
to allow ready access to the UNIX editor of the same 
name [Ref. 26]. 
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e The fiie is parsed using the file command reader, 


invoked with the Do procedure call. 


e Any rule denotations contained in the command rules are 


then activated. 


This process reguires rule files to be reloaded each 
time the interpreter is run. Also, the current implementa- 
tion allows rule activation put not deactivation. These 


limitations suggest the following extensions: 


e A save/restore facility. this facility would copy and 


restore the virtual memory image of the interpreter's 
data segment. 


e A structure editor. There is currently no way to edit 
rule denotations once they are loaded into the inter- 
preter. A structure editor would be useful, particu- 


larly when debugging. 


e Rule deactivation. The akility to remove rules fron 
active status is necessary to allow testing and mnodifi- 
cation. The use of rule names would simplify this 


process. 


3. Parallelism in Omega 


The prototypes discussed in this work have been 
sequential, single-threaded control implementations. An 
important extension to this work is the exploration of 
parallelism in Omega rule interpretation, with architectures 
tailored for concurrent rule evaluation. 

Parallelism in Omega Shares similarities with paral- 
lelism in Prolog. The Prolog literature divides this Paral 
lelism in two categories: AND parallelism (where multiple 


Subgoals ina rule are evaluated concurrently), and OR 
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parallelism (where multiple rules for a goal are evaluated 
concurrently) [Refs 36." p229)- 

in Omega, AND parallelism may be exploited in both 
the antecedent and consequent of a rule. In the antecedent, 
inguiries must be independent for concurrent evaluation. 


Consider the foliowing rule: 
4£ *R1I (x), *R2Z2(x), *K3 (yy) > 2S 


The first two inguiries, R1(x) and R2 (ati; are mutually 
dependent on the variable x. An evaluation order for these 
inguiries should be made to allcw the binding for the vari- 
able x to guide the relation search. The third inguiry, 
R3(y), is independent of evaluation order. An AND parailel 
strategy should separate a rule antecedent into independent 
subunits that exploit concurrency where possible. 

The evaluation of acticns in the consequent of a 
rule has fewer constraints. Any actions separated by comnas 
are potentially subject to ccncurrent evaluation. The 
actions of a sequential block are, however, restricted to a 
Mandatory evaluation crder. 

The evaluation of separate rules in Omega is unord- 
ered; OR parallelism is the norm for the Omega model. A 
parallel implementation of rule evaluation is complicated by 
the shared memory access that many rules require. This 
Shared accesS impiies a locking mechanism at the relation 
level, along with a deadlock-prevention strategy. 

The exploitation of parallelism in Omega offers the 
potential for the resolution of our present performance 
bottlenecks. A parallel architecture that optimizes 
pattern-matching and concurrent rule evaluation would yield 


substantial performance improvemzents. 
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C. CONCLUSIONS 


This thesis has described two prototype implementations 
of Omega interpreters, based cn the model of a LISP-like 
list processing system. Through these designs, we have 
developed a complete LL{1)/LK(1) grammar, and implemented a 
table-driven parser uSing the YACC parser generator. Many 
of the design and igrplementation problems encountered are 
Similar to the LISP deSign issues of the literature. 

The unconventional component of Omega is its pattern- 
directed set of active rules. Our implementation processes 
these rules by a Simple triggering method of rule indexing 
Eased on relation identifiers. Triggering, along with the 
processing of multiple rule gueues, Simulates the concurrent 
evaluation of rules in the Onega model. 

An evaluation of our interpreter's performance indicates 
current execution speeds are slower than Franz LISP and 
Prolog. Possible bottlenecks include excessive recursive 
calls to the central evaluation function, inefficiencies in 
pattern-matching, and execution penalties in storage manage- 
ment routines. While the present design may be optimized to 
improve this performance, other issues are of more interest 
in future research. These issues include alternative repre- 
sentations of relations, alternative control strategies for 
forward inference rule systems, and the exploitation of 
parallelism in Omega. 

Our final contribution in this work is a body of Omega 
programs and some statisticai information on their behavior. 
As the Gmega language matures, this experience may help to 
Characterize potential extensicns and improvements to’ the 


language and its implementation. 
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APPENDIX A 
LEX AND YACC SPECIFICATIONS FOR OMEGA 


J FR RR RR RR RRR HE 2 ee ee a a a oC a a oe a ae Ck I KK CK IE aE 2K 


- x 
- LEX Specification —— x 
* Omega Lexical grammar * 
= x 


FE KF ee EK Ke a I a a a KK KK 


/* lexical scanner grammar */ 


clas ali d 

cetr 
whitespace 
identifier 
int_con 


delimiter 


implication 


deno 

end deno 
ne 

Le 

ge 

mit con 
Ser con 


comment 
%% 


/* 


[0-9 ] 

fa-ZA—Z | 

Nt 

ae elem itty |) e(tivtr} | {digit}))* 
{digit} + 

aes OR) aneeeno s-<>— )) \[ 1 \) 

=> 

<< 

>> 


{digit} + 
NYA peu 
SiN jn 


recognizer actions fcr token classes */ 


Iie Ce 
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{identifier} 


int. con} 


{stxr_con} 


{implication} 


if (strequ(yytext,. ‘22s 
ECGrwEn (LE) - 

else if (strequ(yytext, "elset) ) 
returpatelsen 

else if (stregqu(yytext, "fn")) 
return (FUNCT ROs: 

else if (stregu(yytext, "Nil")) 
return (NIL); 

else 
return ([LDENTIPITER 


return (INT_CON) ; 


C= iInsutoe 

if (6¢°== "Nees 
Un pu tele. 
~~yyleng; 
yymore() ; 


} 


else { 
uUnpuUut (ej: 
EFeGturn (Saha cole 
} 


return (IMPLICATION) ; 
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{deno} { 
return (EEG_DENO) ; 


} 
{end _deno} { 
return (END_DENO) ; 
} 
{ne} { 
return (NE) ; 
} 
{le} { 
Petru rn (Ey: 
} 
{ge} { 
GFeturn (GE) ; 
} 
{delimiter} { 
Betunn (yytext| 0 }) ; 
} 
{conment} ’ 
{whitespace} ; 


Velianore -Orners *+/ 


Ah 


strequ(si, $2) 
char *s1, *S2; 
{ 


return (Strcmp(sl, s2) == 0); 


tracefun (msg) 


char *msg; 


i 
printf ("\n* **%s*** --> ",msqg) ; 
ECHO; 
Prints COs gee 

j 


[RK RRR RR OO ROR RR ok akc ak okie oo ko a 9 aK ok ok a ok a aa 0K ok ae oka ak ake 


* : * 
-- YACC Specification for Omega Parser * 
* * 


BKK AK IK KX a a OK ic 3K a kK KK KK KK Ak OK 3 IK a ie a ea 3K ie a a RK OK ie 2k OK eK aK Ko KK KK a / 
mf 


7 ine ude "tagqan! 


# include "defs.h" 


PTR newcell ({) ; 
PIR Makipe) ; 
PTR MakSte ()) ; 
PTR parsetree; 


char *strdeno () ; 
A} 
/7* type declarations for parser stack */ 


“union { 


PTR cell; 

3 
Atype <cell> session Sstatement_list 
“type <cell> statement ocpd_rule rule cause 
“type <cell> conditions conditicn in¢ uainy 


mtype <cell> constraint transaction transactions 
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Ztype 
“type 
Stype 
“type 
Atype 
Atype 
“type 
~type 


<cell> 
<cel i> 
<cell> 
<cell> 
<cell> 
<cell> 
<cell> 
<cell> 


effect asserticn 
arguments seq_block 
unop binop 


rule denotation 
variable self ref 
fn_definition 
Piha ppl ica eon 


cond_expr cpd_expr 


/* token declarations */ 


“token 
%Ztoken 
Ztoken 
“token 
%token 
*token 


IDENTIFIER 

IF ELSE 
STR_CON INT CON 
IMPLICATION BEG_DENC 
NE LE 
FUNCTION NIL 


/* operator precedance */ 


denial 
expression 


primary 


Constance 
fn_head 
list 
Cal 


END_DENO 
GE 


%left or 

left expression 

*Lleft list 

left '§' "4! 

ALeft ae 

ALeEt Te cr oe NE GE GE 
m~Lert tet va 

%left 7 YG! 


Estart session 


Ah 


/* productions for Omega 


grammar 
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session : /* empty */ 


{ 
parsetree = Nil; 
} 
| cee 
{ 
parsetree = Nil; 


CLeturn (se; 


} 
| statement_list '.! 
{ 
parsetree = $1; 


Eeturcn (pee 


} 


statement_list : statement 
{ 
$$=newcell (STA_LIST,Nil,51) ; 
} 
statement _list ';' statement 
{ 
$$=newcell (STA_LIST,$1, 53) ; 


} 


statement : cpd_rule 
{ 
$$ = $1; 
j 
fn_ definition 
{ 
$$ = $1; 
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cpd_rule — rule 
{ 
S5=neweoell (CPD RULE ,Nil,3 1) ; 
j 
| cpd_rule ELSE rule 


{ 
$$=newcell (CPD_RULE, $1, $3) ; 


j 


rule : IF cause IMPLICATION effect 

{ 
$$=newcell (RULE, $2,$4) ; 
} 

] IF cause IMPLICATION 
{ 
$$=newcell (RULE, 32,Nil); 
} 

| IMPLICATION effect 
{ 
$$=newcell (RULE, Nil,$2) ; 
} 

i effect 
{ 
$$=newcell (RULE, Nil,$1) ; 
j 


cause : conditicns 


Dea) ae 
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conditions : cond i viren 
{ 
S$=newcell (CONDS,Nil,51); 
} 
| constraint 
{ 
$$=newcell (CONDS,Nil,$1); 
} 


| conditicns "7" condieren 


{ 
$$=newcell (CONDS, $1, $3); 


} 
| conditions *,° e€onstracne 
{ 
$$=newcell (CONDS, $1, $3); 
3 


condition 2 oe) AG Uae y 

{ 
$$=newceil (CANC, $2,Nil) ; 
} 

| o> © ie uae 
{ 
$$=newcell (ABST, $2,Nil) ; 
} 

| inguiry 
{ 
$$=newcell (PRES, $1,Nil) ; 
} 
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| 
inguiry ; primary *{' arguments *) ' 


{ 
$$=newcell (INQY, $1,$3) ; 
} 


constraint : expression 
{ 
$$=newcell (CONSTR, $1,Nil) ; 
} 


effect : transactions 
{ 
$$ = $1; 
} 


transactions : transaction 
{ 
$$=newcell (TRANS,Nil,$1); 
} 
j transactions ',' transaction 
{ 
$$=newcell (TRANS, $1, $3) ; 
} 


transaction 4 assertion 
{ 
$$ = $i: 
j 


| denial 


at 


{ 


bd =) pal 
j 
expression 
{ 
SD = oul 
} 
i seg _ block 
{ 
$$ = $1; 
} 
assertion : primary ° (" Vargumencoe 
{ 
$$=newcell (ASSERT,$1,5$3);% 
} 
denial : ‘a! primary '(* arguments *)% 
{ 
$$=newcell (DENY, $2, $4); 
} 
fn_ definition : PUNCTION fn head "2 Wierd vexwou 
{ 
$$=newcell (FN,$2,54) ; 
} 
fn_head : *( dB Guten @ See 
{ 
$$=newcell (FNDCL,Nil, $2); 
} 
| primary '({' arguments eae 
{ 
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$$=newcell (FNDCL,$1, $3) ; 


} 
arguments : VY" eupty «7 
t 
$$ = Nil; 
} 
list 
{ 
$$ = $1; 
} 
| expression ':' expression 
{ 
$$=newcell (CONS, $1, $3) ; 
} 
list : expression 
{ 
$$=newcell (LIST, Nil,$1) ; 
3 
| list ',* expression 
{ 
$$=newcell (LIST, 31,$3) ; 
} 
seq _ block : "{' statement list '}° 
{ 
$$=newcell (SEQ _BLK,$2,Nil); 
3 
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‘{' statement list ae 
{ 
$$=newcell (SEQ _BLK,$2,Nil); 
} 


expression : primary 

{ 
$$ = $1; 
} 

| constant 
{ 
$5 = $1; 
} 

| Cadel 
{ 
$$ = $1; 
} 

' fnvapplacaraon 
{ 
ee 
} 

| rule denotation 
{ 
$5 = $1; 
} 


| unop 


binop 


Sie 


—_ YY) eS 
tH 
il 


"(" cpd_expr oe 
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fied pelication 


call 


rule_denotation 


wae lace? |’ 
{ 
$$ = $2; 
j 
UieecxEEecssion “s* expression ‘'}' 


{ 
$$=newcell (CONS, $2, $4) ; 


primary '['* arguments ']' 
{ 
$$=newcell (APL,51,353); 


j 


primary ={*" arguments *} * 


{ 
$$=newcell (CALL, $1, £3) ; 


} 


BEG DENO statement_iist END_DENO 
{ 
$$=newcell (DENO, $2,Nil) ; 
} 


Doom oiemotatenentelist 's" END _DENO 


{ 


>> 


$$=newcell (DENO, $2,Nil) ; 
} 


unop : '+" expression | ApEcos =— 

{ 
$$ = $2; 
5 

| '-' expression “ApEccwu 
{ 
S$$=newcell (UNNINUS,$2,Nil); 
j 

ia" expression 
{ 
$$=newcell (NOT,$2,Nil); 
} 


binop : expression 't' expression 

{ 
$$=newcell (PLUS, $1,$3) ; 
} 

| expression '-' expression 
{ 
$$=newceil (MINUS,51,53) ; 
} 

| expression '*' expression 
{ 
$$=newcell (MULT, $1, $3) ; 
} 

| expression '/' expression 
{ 
$$=newcell (DIV,51, $3) ; 
} 

| expression '%' expression 


{ 
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$$=newcell (MOD,$1,$3); 


} 

expression ‘=" expression 
{ 
$$=newcell (EQU,$1,53); 
j 

expression '<' expression 
{ 
$$=newcell (LT,51,$3) ; 
j 

expression '>" expression 
: 
$$=newcell (GT,$1,$3) ; 
j 

expression NE expression 
{ 
$$=newcell (NEQ,$1,$3); 
j 

expression LE expression 
{ 
S$$=newcell (LEQ,51,53) ; 
j 

expression GE expression 
{ 
$$=newcell (GEQ,$1,$3); 
j 

expression '&* expression 
{ 
S$=newcell (AND,3$1,$3) ; 
j 

expression ']' expression 
{ 
$$=newcell (OR,$1,$3) ; 
j 


lov} 


primary : variable 
{ 
bd) = oe 
} 
| Selieren 
{ 
DH = 5 1s 
} 


self _ref 3 "od" variable 
{ 
$$=newcell (SELF_REF,$2, Nil); 
} 


variakle : PEN tae ae 
{ 
parsetree = makstr(yytext) ; 


$$=newcell (VAR,Nil, parsetree); 


3 
constant ‘ STR_CON 
{ 
$3 = makstr(strdeno (yytext)) ; 
} 
| INT_CON 
{ 
$$ = makint (atoi (yytexeye 
} 
NIL 
{ 
$$ = Nil; 


io3 


cpd_expr 


cond _expr 


cond_expfr 
{ 
$$=newcell (CPD_RULE,Nil,$1) ; 
} 
cpd_expr ELSE cond_expr 
{ 
$$=newcell (CPD_RULE,31, 53); 


} 


expression 


{ 
$$=newcell (RULE, Nil, $1) ; 


} 


IF constraint IMPLICATION expression 


{ 
$$=newcell (RULE, $2,334) ; 


} 


2 


rc 
Ap 


7* user defined functions */ 


+ include “Lex. y yacu 


/* string denotation routine 
Lexical scanner returns string constants 
with " delimiters included. 


Denotation routine Simply removes the extra "s. 


char *strdeno(s2) 
Char *s2; 


{ 


char *s1; : 
sl = sz2 + 1; 
* (S11 + (strven(sl)—1))), =. xt 
return (s1); 
} 
/* error handler 


Prints error message and line number where error occurred. 


No attempt made to recover from errors. 


yyerror (msg) 
Char *msg; 
i 
PLLDtL ("As 2. esol: 
printi ("line Ad\n", yy dimeror, 
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APPENDIX B 


BUILT-IN FUNCTIONS AND PROCEDURES 


me. Built-in Functions 


iMeeLnias ODeEraALOrsS =— 


op 


type 


Ser. * 4st l=? 
1) cee > 
it 
tt 


" (modulus) 


ant xX int => 


any Xsany -—> 


any xX any -> 


Str (concatenation) 


suid 


Bool 


Bool 
Bool 


Bool x Bcol -> Bool 


Bool x Bcol 


Unary operators : 


Int -> Int 
Bool -> Boo 


B. System defined functions ; 


isint[iten] 


IsStr[ iten ] 


-> Bool 


1 


-- Returns TRUE if iten 


iS an integer. 


16 1 


. -- Returns TRUE if iten 


IsList[iten] 


IsObj[ item ] 


IsRelf iten] 


Ineo SCE ia nes) 


ELEStOL is © | 


rest[{[ list] 


Cons sc, == | 


objvalj object } 


1S a String. 
Returns TRUE if iten 


is a list. 


Returns TRUE iz item 


iS an ObjeGceE- 


Returns TRUE if item 


is a relation ongjece 
Integer to string conversion. 


CAR. Returns the first nenber 


Of tani. Sue 


Chk. Returns all members of 


a list after the first member. 


Returns a new list with x as its 
first member and 1 as the rest of 
the list. The notation [x:l] 


does the same thing. 


Returns the value bound to an 


Oonjiect. 


The following oktjects have bound values : 


relations 


functions 


rule denotations 


directories 


Tagj forn } 2 


Returns a string representing the 


tag of fo cue 
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HE < 


Built-in Procedures 


A« 


General usage: 
do{"fiienane"} 
activate {name} 
decode {forn} 
display {forn} 


displayn {for} 


define{dir,"name",def}-- 


trace {} 


exit 9 


newobj {3 
newrel {} 


purge{relation_nane} 


UNIX system hooks: 
vi {"file'" 


systen {"command'"} 


shell {3 
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Executes rules from file. 
Activate rule denotation. 
Post order dump of nodes. 
Pretty printer. 


Pretty printer. Ends 


with a newline. 
Make a directory entry. 
Toggle the trace function. 


End session. 


Same as Cnt1l-D. 
Generate a new object. 
Generate a new relation. 


EUpreysas relation. 


Invoke the VI text editor. 


Pass a command to the 


UNIX shell. 


opawn a temporary 


UNIX shell. 


APPENDIX C 
UTILITY FUNCTIONS AND RULES 


TYITPTITrPTrrerrrrr rrr rrr y rrr rats a bt 8 ieee ieee 


Fun¢e tion 1 brary 


TITTY TrTrTrTTrrTrrrrrrrraer rrr); rrr itt Pith ho aii 


fo 


fn 


im 


fin 


iT 


er 


eo # @eeee#ee@e#eee3ee#ses @#@ee#@e##ee#@e#e*e 02 # @ @ @ @# @# @# 8&8 &#& & @&.—6UMOUCUCOhUchHhMU—C OHmhUhUhOmhUCUC OhUh!HmhUhC 


A dummy forward declaration is used for reverseAux 


due to single pass static scoping. 
reverseAux[ x] : Nil. 
reverse,1] : reverseAux{[l, Nil]. 


reverseAux[ 11, 12]: 
Ti) = eae => ee 
else 


reverseAux[ rest[11], consj first, 11], 12] 


Mapp cele ee 
Pi be. Ne 
else 
cons[fi[ first[1]j, mapli,  ,este yar 


member[ x, 1] 
1f 1) = Naa aa 
else 1f x = first[1] -> l 


else member; x, rest{[1]]}. 


aSSocl x, 1 lm. 
if a =_ Nal => eNae 
else if 71 Islistjfirst[1]] | first{[1] = Nil 
-> assoc| x, rest[1]] 
else if x = first[first[1]] —> 222205 


else assoc{ x7 Bestar 
Palrigst( Val eee 
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if 11 = Nil | 12 = Nil -> Nil 
Scoomeons, | LirSuil |, L£AabsStl 12) ), 
pairlist{rest[1i1], rest[12]]}}.- 


my append! ti, 12) : 

ieeeeae = Nal => 2 

else if 12 = Nil -> 11 

else cons[first{11], append[rest{11], 12]]. 


moeiotafhi, n2Zj] : 
ieee 22 > NGL 


else cons[ ni, iotaf[nit+1, n2}]j. 


me Lrength{ 1] : 
er el — Neo 
else 1 + lenyth[ rest[ 1] ]. 


mieotbp tl, 1] : 
ie <= a 
else if 1=Nil -> Nil 
else ith[restj1l], i-7]}. 


Tok a ok ak kok ok ok kkk kkk ok ok dak kk ko ok kok kc ok ok 
} Utilities -- : 
! This file contains a set of utility | 
' rules that are automaticaily loaded ! 


! at system boot. : 
Tok kk kkk kok ok ok kok ak kok kk kk kok kkk ok dk kk ok kK 


1 System Help function 


define{root, "help", newrel {}}. 


definef{root, "HelpLib", newrel {}}. 


Pore Lib (v2, "/ywork/mcarthur/common/summary-e-help"). 
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HelpLib("relations","/work/mcarthur/common/relation, help am 
HelpLib ("f£unctions", "/work/mcarthur/common/ifunction. nee pa 
HelpLib ("procedure","/work/mcarthur/common/procedure.help") . 
He lpi Vaugs, "/work/mcarthur/common/bugs.help"). 
HelpLib("Ssample™, "/work/mcarthur/common/sample.heip 
/WOLCK/MCALTAUL/CONNON/ ~.n ue ee 


HelpLib( "features", "/work/mcartnur/common/features. help"). 


definef{root, "HelpRules", 


\ 


<< 
! this rule may be invoked by an assertion or a call 
y so both cases are covered. 


if *nelp(a:L), (-1SRel[a] | Length. —si 
displayn{"Usage : help {""topic'™ ie 
help {"?"} 


else if *help(a, x), HelpLib(x, y) -> 
system ("more " + y), 
a OK") 


else af *nelp (ajax) 
displayn ("Topic not founds je, 
hep (ayya es ie 


ee 


! Activate the rules 


activate{ HelpRules }. 


displaynf{ "Por help, enter help gmap oa oe 
displaynf}. 


: bug rules --- add to the bug documentation 


define {rootyaBugkudes | 
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<< 

me * Bugs (a) —> 
display eScmivgemencmrNg. ENdsween Cntrl-D :"}, 
systen{"mail -s "Bug Report! mcarthur"}, 
a ("OK") 

>>} - 


define{root, "Bugs", newrel {}}. 
activate {BugRules}. 


displayn{"To report a bug, enter Bugs{}."}. 


! CopyRel -- Copy from one relation to another 
! Usage iS CopyRel{R1, K2}. 


define{root, "CopyRel", newrel {}}. 


define{root, "CopyRelRules", 
<< 


mmecopyRel({a, ci, r2), rvri(x:y), ~r2(x:y) ~-> 
in ( Xs y) 


else if *CopyRel (a, ri, r2) -> 
a ("OK") : 


>>) 


activate {CopyRelRules}. 


: pp - A pretty printer fcr objects. 

! 

! These rules are reguired because the standard pretty 
! printer - display - doesn't do lookups on objects. 

u 

! define the relations.... 
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—< 


<< 


define {root, "Pp", newreliiae 

define froot, “PpAux", newreliee 
define {root, "DoReL", newrel {}}. 
define {root, "PpObj", newrel {}}. 


definef{root, "DumpDisplay", newrel {}}. 


the rules ... 


define {root, "PpRules", 


! single member is a gocf by the user 
af *Pp (ach) olskel) age 
displayn{"Usage * Pp{xl, x27... 


ite Fep{asNi.) 7 
a (""O Ky 


else 1f *Pp(a:[x:L])} -> 
ODAUX IZ} 
Pp (ail) ; 


[> TSGiot ear Gb € lava Olu 
It COSPpAUx (a 4) ESR eres ee 
PpRel{x, newrel §}, 


a (tah) 


"Or Other type of 2007 coma 
else if *PpAux(a, x) 1sObi ial 
PpOb (a4, XX, -0D3 val) xe 


a Cee) 


! otherwise just display it 
else if *PpAux(a, x) -> 
displayn {x}, 


a (tt) : 
if *PpRel(a, x, temp) -> 
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CopyRel {x, temp}, 
DumpDisplay(a, x, temp); 


PopanpDLSPLay (aeaemale yeh), “Kh (x:y) —-> 
display {name}, 
display{"("}, 
display {x:y}, 
displayn{")."}, 


DumpDisplay(a, name, R) 
else if *DumpDisplay(a, name, R) -> 
a(n) : 


! Pretty print objects ... 


! Functions require a bit of set up 


if *PpObj(a, name, def), Tag[defJ="FN" -> 
dvspilay {in "3 > 
display {name}, 
displayn {def}, 


a Celt) 
! otherwise, just display def (might be Nil) 


else 1£ *PpObj(a, name, def) -> 
displayn{def} ; 


>}. 


activate {Ppkules}. 


! assert list procedures 
! allows one to assert multiple tuples to a relation 
! Usage is Assert{relname, [tuple], [tuple], ...} 


definef{root, "AssertList", newrel {}}. 


define{root, "AssertAux", newrel{}}. 
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definefroot, “AssertTuplie", newrei {}}.- 


define{root, "AssertListRules", 
<< 


if *AssertList(a:jr:L]), IsRelf aj, iIskell. e 


AssertAux(a, fr, L) 


else if *AssertList(a:L) -> 
displayn{"Usage : Assert{Relname, ListOfTuples}"}, 
a (Nad); 


if *AssertAux(a, r, Nil) -> 


a("OK") 


else if *AssertAux(a, cr, {[x:1l1]) -> 
AssertTuple{r, x}, 


ASSert Aupetay ee ela. 


if *AssertTuple (a, ©, Xx), 7=aiSia ste 


displayn{"Error in Assert -- tuple not a liste 


else if *AssertTuple(a, r, Nil) -> 


a (Nil) 


else if *AssertTuple(a, r, [x:1 °) -> 
EAX Say 


a) (i): 
>>is 


activate {AssertListRules}. 
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APPENDIX D 
COMPARATIVE APPLICATIONS: OMEGA, LISP, AND PROLOG 


We He ee HK oe ee ae ie eK ae a ee oe ee a ie a EK RK I KK OK KK 


* * 
* Patrermetacenangd 1€scs * 
* * 
* * 


WK ee Ko ee i ie a a ae ae ae ee a a oe eK ae oe eae ie ie eK ee a ee a a ek ok 


! pattern matching benchmark -- Omega 


define{root, "R1", newrel {}}. 
define{root, "R2", newrel {fj}. 
define{root, "genDat", newrel {}}. 


define{root, "mTest", newrel {}}. 


define{root, "MatchRules", 
<< 


!' the data generating rules 


mergenDat(a, ni, n2), ni> n2 -> 
a ("OK") 

puse if *genDat(a, nil, n2) -> f{ 
Realm) ; 


Reem tt 2) * 
genDat(a, nit+1l, n2); 
} 

if *mTest(a) -> f{ 
Ramos 9 De R2 (9999) : 
genDat {1, 1000}; 


17 1 


systen {"date"} ; 

af R(X) pene Cee 
systen("date") ; 
displayn {j_: 
}; 

an(stOn) : 

5 

hee 


! activate the rules 


activate {MatchRules}. 


/* 
PROLOG pattern matching benchmark 
ma ee * / 
edi 3S .o)es 
E249 799 e- 
genDat(Lo, Hi) :- 
Loe <n doe, 
TZ etSe0 +) ia, 
asserta(ri(Lo)), 
asserta (r2(I2)), 
bonext 12s Lo + 1, 
genDat (Lonext, Hi). 
genDat(Hi, Hi). 
mTest (X) :- 
genDat (1, 1000), 
system ("date"), 
EI() > 2, 
system ("date"). 
: pattern matching benchmark —— Franz 
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(defun genDat (ni n2) 
(prog (11) 
(setq i1 n1) 
LOOP 
(cond ((greaterp i1 ng@) 
(return) ) 
(t (setg r1 (cons i1 1£1)) 
(setq Eb2 (corsm(plus if n2) £2)) 
(setq i1 (add1 i1)) 
(go LOOP))))) 


(defun match () 
(DEOGs Gl EZ) 
(setg t1 r1) 
LOOP 1 
(setgq t2 r2) 
LOOP 2 
(cond ((null eZ) 
(cond (({null t1) (return nil)) 
(t (setgq t1 (cdr t1)) 
(go LCOP1)))) 
(teqgual (car © ijie(Car t2) ) 
(return (car t1))) 
ft (seta etluearst2) ) 
(go LOOP2))))) 


(defun mTest () 
(setg ri (list 9999) ) 
(setg r2 (list 9999)) 
(genDat 1 1000) 
(exec date) 
(match) 


(exec date) ) 
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He ee oe a ae oe ae ae A Ke a ae Ke a ae KO Ie ie oe Ke IK 2 OK A ae KK aK KK Ok OK 


Pa 


x Factorial 
* 


Pa 


x 


* 


* 


xk 


Me ae KE A Sk ae ie a a aK ie KK KK eK ae a eK eK KK oe A KK KK KR KK OK a eae KK OK ok oe ok ok 


! factorial benchmark -- Cmega 


fh Viaeel nm]. 
Pr ne <= Oe eel 


else n * fact[n-1]. 
 “deaver rules 


define{root, "Driver", newrel {}}. 
define froot, "factTest", newre impr 


definef{root, "DriverRules", 


<< 1f *Driver{a, n) -> { 
If peat 0 =o aOR) 
else -> { 
fact f to): 


Driver(a, n-1) 
} 
}; 


am 


the CSH date function provides a timer 


fe nee 


times given to the nearest second 


if §fcactrest lap l= — oat 
display{"Omega factorial 
display {n}; 
displayny{ calles 
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systen("date") ; 
Driver {n} ; 
system("date") ; 
}; 

D>] - 


! activate the rules 


activate {Driverkules}. 


J/* 
mactOrial benchmark -- Prolog 


met (N, t) :<- N =< 0. 
miei (N, F) :- 
N >= 0, fact (N-1, M), Fis M * N. 


driver(0). 
driver(N) :- 
NEP me aGt (to ek) yet is N= t, driver (M). 


factTest(N) :- 
system ("date"), 
driver (N), 


system ("date"). 


; Factorial benchmark -- Franz LISP 


(defun fact (n) 
(cond ((lessp n 0) 1) 
((zerop n) 1) 
Coie en (facua(- en 1)))))) 


tS 


* the benchmark driver -- 
; (fact 15) executed n times 
(defun driver (n) 
(cond ((equal nO) "OK'') 
(tac) 
(driver (- n 1))))) 


; the CSH date function provides a crude 


; timer to the nearest second. 


(defun factTest (n) 
(exec date) 
(driver n) 


(exec date)) 


FE Ke Ke ee oe ee a oe ie oe i eK oe ie oc oe a i ie oe oe oe oe ok ok 


* x 
* Prime Number Sieve * 
x * 
* x 


FE KK KK i oe 2c ee ie ae 2 2c ee a ie oO oe eK a ASK Ok kK 


! sieve benchmark -- Omega 


define{root, "Primnes", newrel {}}. 
define{root, "PrimesAux", newrel{}}. 


definef{root, "sTest", newrel {}}. 


fn PurgeMults[ x, 1] : 
if,id.= Nae] oa 
else if first{l] % x = QQ -> 
PurgeMults[ x, restj;1]] 
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else [first[1]:PurgeMultsjx, rest{[1]j].- 


define{root, "Sievekules", 
<< 
if *Primes({a, n) -> 


PEPMesAux (dy) 1Otdai 2,5 0), Nil): 


if *PrimesAux(a, Nil, 1) -> 
a(reversef 1 }) 
else if *PrimesAux(a,[x:11], 12) -> 


PrimesAux(a, FurgeMults;x, 11], [x:12]}); 


Heo *STest(a) -> { 
systen {"date"} ; 
Primes {350}; 
systen {"date"} ; 
aut OK): 
33 

>>}. 


activate {SieveRules}. 


/* 
Sieve benchmark -- Prolog 


primes(Limit, Ps) :- 
HOtd (270 Limit, Is), 
Sittaues,. PS). 


Beta({lo, Hi, {LolRest)) :- 
Lo =< Hi, M is Lot1, iota(M, Hi, Rest). 
mota{ , _» [ })- 
pee ({ _, [ })- 
Sere {{Lj)is}], [Ij1Ps]) :- 


remove(i, Is, New), sift(New, Ps). 
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Beno (Pi |y) toes 

renove(P, [ilis], [i] Mis]) <= 
not(0O is I mod P), 
remove(P, Is, Nis). 

remove(P, [I]lIs], Nis) :- 


Ois I mod P, remove(P, Is, Nis). 


sTest ;:- 
system ("date"), 
primes (350, Ps), 
system("date"), 
Print CP sire 
: Sleve benchmark -- Franz LISP 


(defun iota (nil n2) 
(cond ((greaterp ni n2) nil) 
(t (cons nl (Lota (addi niljenZipeee 


(defun purgeMulits (x 1) 
(cond ((null 1) nil) 
((zerop (mod (car 1) X)) (purgeMults x (edr ae 
(t (cons (car 1) (purgeMNuits x cde topes 


(defun primes (n) 


(primesAux (iota 2 n))) 


(defun primesAux (1) 
(cond @@Giw) 1 a aenais) 
(t (cons (car ll) 
(primes Aux 
(purgeMults 
(car 1) 


(cdr 1))))))) 
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(defun sTest () 
(exec date) 
(primes 350) 


(exec date)) 


He Ae Fe oe eK a ee I A eA a oA A oe IR AK IK KE OK OK ARK KK OK OK OK 


* 
* Quicksort 
* 


x 


oe 


* 


a 


<< 


KK kk kk ka KK kok KK KKK RK KKK KK KKK RK KKK 


] Quicksort benchmark -- Cmega 


mmetotaR(/ ni, n2] ;: 
Peete eis —> Ni] 


Srcwenz:tOtan ni, m2—-1— ]- 


define{root, "Qsort", newrel {}}. 
defrinef{root, "QsortAux", newrel {}}. 


define {root, "qTest", newrel {}}. 
define{root, "QsortRules", 


<< 


! Ouneck. Sort 
if *Qsort(a, Nil) -> 
ai Nab yes 
emer OSOLt(a, {x:L]) -> 
Csoursuxi(a, <7 i, Nil, Nil); 


es 


aE *OsortaAux (a, x, Ned ole ee 
a({append[ Osort{L1}, |x: Csort fiz 
1f *QsortAux (a, x, [| y:b1), LZ, ee 
if y <= x -> 
OSortaAux (a, x, Ili; | yo eZee 
else 
QsortaAux(a, x, 11, £2, yee 
35 


af *QTeCS tae 
systen {"date"} ; 
OSoEtizotak[ 1, u5) 
system {"date"}; 
at Oa 
33 

oo hie 


activate {QsortRules}. 


a Quicksort Benchmark -- Frolog 


GSort (f Hii see: 
Sp ee He ten oe 
GSOrt(A,A1), 
qsortts 3 1). 
app enanaA (, (Hiei, 5). 
gsort({ ], ( ))- 


Spi ae (ee ade Aull ee 
A < H, 
Splat tie Yee 

sfc iO In en iielvA gy) S— 
H< A, 
split (hye 

Spe tei) lady ese 
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append ([{ ],L,1L). 
append({HIT],L,[HIV]j) :- 
append (2,4, V) < 


Moeak (Lo, Hi, [{HijRest]) :- 
LOe=< Hiei ts Hi- Vs 1Otan (Lo, HM, 
Hotakn({ , , [ })- 


gqTest (N) :- 
system ("date"), 
HoOtak.( 1, NL), 
GSOErt(L, Sia, 
system ("date"), 


PELRE(S): 


> Quicksort Benchmark -- Franz LISP 


© cme cme ce re ce ee re ce cs ce cc wr es es es es ee es se se es 


{defun gsort(l) 
feond ({nuil I) nil) 


Rest) . 


(Ee (setq Swilspiat (cammiemeicdr 1))) 


(append (qgsort (car Ss)) 
(icons (Cat 1) (gqSert 
(defun split (x 1) 
(prog (Ss) 


(cadr s))))))) 


(cond ((null 1) (return (list nil nil)))) 


(setg s (split x (cdr 1))) 
(cond ((lessp (car 1) x) 


(return (list (cons (car 1) (car s)) (cadr s)))) 


(t 


(ceturn (list (car Ss) 


181 


(cons (car 1) (Cadi =s)) eae 


(defun iotaR (ni n2) 
(cond ((greaterp ni n2) nil) 
{t (cons n2 (iotaR ni (subi n2)))))) 


(defun gqTest ({n) 
(exec date) 
(gsort (iotaR 171 n)) 
(exec date) ) 


We IK a a a ae ie a oe Hk ok ok ac oe ie a oe oo a a oe ok ok a a KK eK ke ie ok 2 ek ok 


Massionaries and Cannibals: 
A State Search Problen 


He # # & # 


AK KKK KK 2 a a a CK OK OK a A a oe oe oe kK OK AK OK OK a aK ok a a eK RK KK OK KK IK Ok OK 


! Wissionaries and Cannibals -- Omega 


' Generate and test search strategy 


define{root, "nc", newrel {}}. 
definefroot, "misCan", newrel {}}. 


define{root, "PpL", newrel {}}. 


define{ root, "misCanRules", ) 
<< 
if *mc(nM, nC) -> 
misCan({1,nM,nC,nM,nG,0,) 07 ae 
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* 
x 
* 
* 
* 
* 


PeiToecmis ent, nc,0,0,nt,nCc, path) 

SS f 
purge {misCan} ; 
Probris,0,0, 1%, nC |; path }} ; 
displayn{"Finis"} 
} 

else if *misCan(s,ni,nC,mL,cL,mR,cR,path), 
(mL >= 0 & mL <= nM & 


cL >= 0 6& cL <= nc & 
mR >= 0 & mR <= nM & 
CR >= 0 & cR <= nC & 
(i> —elleanre=—0) & 


{mR >= CR | OR Oj, 
-mnembkerj [S,mL,cL,mR,cR],path } 


ivseanneU—<c) NN nc NL—-s,cL,mRts,cR, 
Siac th, Cums Da.en  ) > | 

icCanmto-s) uit, nC,0L,cL-S,NR,cKts, 
SPlu,cr, Mk,CR {path ) 44 

Lrseaiimooeiienie, ML,cL=2*S,0R,Cht+2 *S, 
Seu, cl,Mh, Ck s;pach ) | | 

seam OS) nl, nc ,0L-2*s,ch,mk+2*s, ck, 
SplivgGl, Mi eRe. pach ) , } 

bIsceCani (0 —s) nu ne, lu-s-cL-s,mk+s, cR+ts, 
cyl, Cu, Nh,chn t!path ) =) | 


Siccmlme iio Cal( s,m M,N ;llL,eck,mn,ch,Ppath) —>; 
! asmall pretty printer for the output list 


De *PpiL (a, Nail) <-> 

else 1£ *PpL (a, [x:1]) -> f{ 
PpL {1}; 
displayn {x}; 
} 


See 
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activate{ misCanrkules }. 


/* 
Missionaries and Cannibals -- Prolog 


mc (Nm,Nc) :- pisCan(-1,Nu Ne ,07 Oia Nei ee 


misCan(S,;Nm,Nc,Nu,Nc,0, 0, Pawn) eee 
Nm >= Ne, ppLlLii[ s,Nm Nc 070 eae pe 
misCan(S,Nm, Nc, M1,Cil , Meer eae ee 
safe(Nmn, Nc, Mi,€1, ur erie, 
equal ([ Syl, GCigeiie (Ce lp ei, 
not (member (P,Path)), 
Sivis )=s5 
possible (S,M1,Ci, Mr ,Cr, Ml i; Clive Cee, 
misCan (S1,Nm,Nc,M11,C11 Mel, Cr 1,2 | racu ee 


safe (Nn Ne, ll el Na, Cra. 
M1 >= 0, Ml =< Nao, 
Cl. Oe 707 Gi =< Ne, 
(Mi >= CL 5) Nig. =e 
(Mr >= Cr: Mre—--—. 0). 


possible(S,mi, C1 Mr, Cru 1,Cil, Pel eel) aa 
(ses Se iS 
Mepis Netra, 
Cll as4Cci, 


Cray is CEs 


(M11 is Ml, 
Mr1is Mr, 
Ci 2S Gi Zs, 
Cll. 2S Garo 
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(seo ; 
Mriis MrtsS, 
ey 15 “Cl=S. 
Grrl, Vs tert s):: 
(M11 is M1-S, 
Mriis Mrt+s, 


Cit SC, 


Gm 1S Cr): 


(ao) 1S Mile, 
Mriis Mr, 
Cr ts eer-> 7 
Cr Ser +S) 


Peiocm te, | i), s- !',Laii. 
member(X,[X|L]}). 
member(X,[Y}{L]) :- member (X,1L). 


ead. (X,X) « 


ppL([ ])- 
Poie(; Xiij) <-> print(xX), nl, ppl). 


Ne 5 


APPENDIX E 


OMEGA APPLICATION EXAMPLES 


Vo 2K 2K KK EK OK OK AK OK OK OK KK OK OK ok eK ke KK a OK OK ie eK OK OK ik ok eK KK ok kK KK 


: 


! Monte Carlo Simulation for 3 node message network. 


: 


: 
' 


! 


Vo 3 2 2 eK a Ke RK EK KK KK OE KK KK OK aK aK eR AE OK 3K OK OK OK KK OK OK OK OK ok KK OK aK OK ok kok ok 


! the relations 


define{root, 
define{root, 
define{root, 
define{root, 
define{root, 
define {root, 
define{root, 
define{root, 
define{root, 
define{root, 
define {root, 
define{root, 
define{root, 
define {root, 
define{root, 
define{root, 
define {root, 
define{root, 
define{root, 
define{root, 
define{root, 
define{root, 


define{root, 


"Begin", newrel {}}. 
"tEnd", newrel {}}. 
"Clock, “ewe fie. 
"NextTime", newrel $B}. 
"LastTipe", newrel {}}. 
"Event", newrel {}}. 


"ProcessEvents", newrel {}}. 


"ProcessEventsAux", newrel {}}. 


"Summary", newrel {}}. 
iMStatust, newrel }}. 
"BusyTime", newrel {j}}. 
"OLength", newrel {}}. 
"Stats", newreil{} }.% 
"BusyStats", newrel{}}. 
"OStats", newrel tj 
"Totals", newned. (ia. 
"NodeTotals", newrel {}}. 
"JobTotals", newrel{}}. 
"JobTotalsAux", newrel {}}. 
"Displayline", newrel {}}. 
"Start!" ,newrele 
"Arrive", newrel{}}. 


"NewArrival", newrel {}}. 
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define{root, 
define{root, 
define{root, 
define{root, 
defrine{root, 
define{root, 
define{root, 
define{root, 
define{root, 
define {root, 
define{root, 
define {root, 
define{root, 
define{root, 
define {root, 
define {root, 
define{root, 
define{root, 
define{root, 
define{root, 
define{root, 
define{root, 


define{root, 


"Service", newrel {}}.- 
"StartTime", newrelj}}. 
"Depart", newrel {} }. 
uepxitTime", newrel {}}. 
"TInService", newrel{}}. 
"Oo", newrel {}}. 

"Eng", newrel {3}. 
"CalcNextArr", newrel {}}. 
"CalcDeparture", newrel {}}. 
"CalcRoute", newreil {}}. 
"NewJob", newrel {}}. 
"JopServiceT", newrel{}}. 
"JobCount", newrel §}. 
"GenArrT", newrel {[}}. 
"GenServI", newrel }}. 
"GenRoute", newrel {}}. 
"ServiceTine", newrel {}}. 
"Arrinterval", newrel {}}. 
"PossibleRoutes", newrel {}}.- 
"Seed", newrel {}}. 

Rnd", newrel {}}. 
"RndList", newrel {}}. 


"WorkList", newrel {fj}. 


! the Nodes 


define {root, 
define{root, 
define{root, 


define{root, 


yee 


"Nodei", newobj {}}. 
"Node2", newobj {}}. 
"Node3", newobj {}}.- 
"Out", newobj {}}- 


initalize MonteCarlo takles 


: Service times (message transmission times) 


ServiceTime (1, 0, 12). 
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Séry teetine (2, sic 
ServiceTine (3, 33, 
ServiceTime (4, 80, 


ServiceTime (5, 93, 


! TInterarrival times 


Arrinterval (Nodel, 
Arrinterval (Nodel, 
Arrinterval(Nodel, 
Arrinterval (Nodel, 
Arcinterval (Nodel, 


Arrinterval(Node2, 
ArriInterval (Node2, 
Arrinterval (Node2, 
Arrinterval(Node2, 
Arrinterval (Node2, 


ayes 
Toe 
92). 
99). 


1, O, 
2 tee 
3S 
4, 50, 
Sac) 


eo, 
Deo 
307 de 
i Ser 
Sel 


! Routing table 


PossibleRoutes (Nodel, 
PossikleRoutes (Nodel, 


PossibleRoutes (Nodel, 


PossibleRoutes (Node2, 


PossikleRoutes (Node2, 


ene 
24). 
49). 
91). 
99). 


Ze 
oe 
85) . 
92). 
99). 


NodeZz 7) - 0 7ez le. 
Node3, 30, 59). 
Out, 


60, 99). 


Nodel, O7,829)2 
Node3, 30, 49). 


PossibleRoutes (Node2, Out, > Oo) 
PossibleRoutes (Node3, Out, O79) 
! Random number table 

RndList ([ 


97,95, 12,11,.90,49-57, 13.80 5cur 
02,92,75,91,24 , 58,39 ,22,13¢02, 
80,67, 14,99, 16,89, 96 ,63,00,04, 
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——s LL _<—<«£ 0.“ =—<<_ - °° 


epic 20 28,72. 12,77,23,79,46, 
DEG, S26 73 o4, 26, 18,37,31, 
50,02,74,70,16,85,95,32,85,67, 
29,53,08,33, 81, 34, 30,21, 24,25, 
bemiio 01,91,70,07,50, 13, 18,24, 
51, 16,69, 67, 16,53, 11,06,36,19, 
04,55,36,97,30,99,80,10,52,40, 
86, 54, 35,61,59, 89,64, 57, 16,02, 
e235 .52,11,59, 10,98,68, 17,39, 
39, 36,99,50,74,27,69,48, 32, 68, 
60,71,41,25,90,93,07 ,24,29,59, 
65,88,48,06, 68, 92, 70,97, 02, 66, 
u4,74,11,60,14,57,08 ,54,12,90, 
Bay 10,95;80, 32,50, 40,44;08, 12, 
20,46 ,36,19,47,78, 16 ,90,59,64, 
86,54,24,88, 94, 14,58,49, 80,79, 
i259, 12,25,19,70,40,06,40,31, 
42,00,50,24, 60, 90,69,60,07, 86, 
2996 ,81,68,61,24,90,92, 32,68, 
Ben 6 3,02,37,89,40,81,77,74, 82, 
01,77,82,78,20, 72435 438,56,89, 
41,69,43,37,41,21,36 ,39,57, 80, 
54,40,76,04,05,01,45,84,55,11, 
peo 82,32, 22, 90, 92,47,77,62, 
21,31,77,75,43,13,83,43,70,16, 
53,64,54,21,04, 23, 85,44,81, 36, 
91,66,21,47,95 ,69,58,91,47,59, 
Me 2,74,40,97,92,05,01,61,18, 
Pe, 21,47,71,84,46,09,85,32, 82, 
55,95, 24,85, 84,51,61,60,62, 13, 
70,27,01,88,84,85,77 ,94,67,35, 
38, 13,66, 15,38, 54, 43,64, 25,43, 
ene0 ,25,24,92,98,35, 12,17, 62, 
98, 10,91,61,04, 90,05,22,75,20, 
mo ,29,19,26,26,87,94,27,73 
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]) - 


HOPKINS ec (Nd lyre 


! Intialize Queues 


Q(Nodel, Nil). 
Q(Node2, Nii). 
Q(Node3, Nil). 


oa 


the Precedence function 


eow 


Scheme 1S (for events @time=t, node=n) 


! Departures have top priority 


eas 


Between occurrences of same type of event 
JOobN1 precedes JobDN2 if N1 < N2. 


oe 


e—~ 


This function replaces a sort on the event list. 


fh Precedencefel, jl, e2, j2]: 
if el=e2 §& j1<j2 -> "TRUE" 
else 1f el=Depart & e2 -= Depart -> "TRUE" 


else Nil. 


! The Rules 


define (moor, “Satkutes, 


<< 


; Begin -- Begins the Simulation and sets up relaticns 


eas 


Iie Begin (a) eee ae 
JOoDCOoUnt (0. 07. 2): 
LastTime (0) ; 


Te 


———— tt tt 


Tmiscervace (Node, “——") ; 
miserviee(Node2, “Ne=4"').; 


iioervace (Nodes ,.U=—*") > 


BusyTime(Nodel, 0); 
BusyTime (Node2, 0); 
BusyTime (Node3, 0); 


OQLength (Nodel, 0); 
CLength (Node2, 0); 
QLength (Node3, 0); 


Event(0, Start, "--", "-——"); 


Cloer (0): 


a("OK") ; 
33 
! 
] Eide =-—-wCLeanuperor £urt heberuns 


if *End(a) -> { 
purge{JobCount}; 
purge {InService}; 
a(End); 


eg 
! the clock rules -- drives the simulation 


mee Clock (999), *LastTime(t) -> { 
Totals {t}; 
End {}; 
} 


else if *Clock(t2), *LastTime(t1) -> { 


19 1 


Statsft' e2y3 
displayn { 


display (Uli mes se 
displa yn {t 2}; 
displaym (hy ents ane. 
ProcessEvents {t2};: 
Summary {}3 
LastTime (t2) ; 
Clock (NextTime {999} ) ; ! restart £he eloe. 
33 
1f *NextTime(a, tl), Event(t2, <, 2, 3) 22 eee 
NextTime (a, t2) 


else if *NextTime(a, t) -> 


ane) >, 


ous 


! Process all events for time t 


if *ProcessEvents(a, t), Event(t, el, ni, jl) -> { 
ProcessEventsAux{t, el, nl, jl}; 
ProcessEvents(a, t) ; 


} 


else if *ProcessEventS(a, t) -> 
a(t); 


1£ *ProcessEventsAux (a, t, el, nl, 31), 
Event (it, €2, N27 e77)4, 
Precedencej e2, j2, el, jlj -> 


ProcessEventsAux(a, t, ¢€2, nz, j2) 


else if *ProcessEventsAux (a, t, e, node, job) -> { 
aEvent (t, e, node, job) ; 


e{t, node, job}; 


WZ 


display{" mes 
displayn{e, node, job}; 
att), 

} 


Summarize the current status for all nodes 


if *Summary (a) -> { 


Status {Node1}, Status{Ncde2}, Status {Node3} ; 
displayn {3}; 

displayn{"Pending Events :"} ; 

Pp {Event} ; 

displayn {}; 


a Cit) . 


3 
if *Status(a, node), InService(rode, job), Q(node, 1) -> 
{ 
displayn {node}; 
daspilay {! Job in service : "}; 


ir) 


Caw 


displa yn {job}; 
display {" NOpSwina queue), } ; 
tf lave => ediscplayn {'=—"} 
else displayn {1}; 
a (node); 


Hee 


Keep running tctals for stats on each node. 


The relations are : 
BusyTime (node, t) -- Cumulative idle tine 
QLength(node, n) -- Time weighted Q length 
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af *Stats (a, t lero a ot 


BUSYStatatti, tz, Nede te. 
BUSYStatsiti, €2, Nodezi 
BUSY Stars et, tc, odcans 
OStacs eel) tz, NOde te 
OStatst i, > tz, Nodezi 
OStatsitti, tz, Nodeur 
atta, 

}3 


if *BusyStats(a, ti, t2, node), InService (nece,-—') ae 


a (node) 


else if *BusyStats(a, t1, t2, nede), *BusyTime(node, Tie 


Busy lame (node, ttt2—¢ 1) a, 


a(node) ; 


1£ *QStats(a, ti, t2, node), *Qiength(node,n), 0 (node; 


aan 


6— 


OLength (node, n + (t2-t1) *Pengrns ie 


a (node) ; 


Totals -- Display stat summary at end of Simulation 


if *etal sia te => 


dirs Daye Total. Eanes ais, 
displayn {t}; 

displa yia@: 

DisplayLine {["Node", "Busy tae oOlentaihe 
DisplayLine {[ "---=-++-==—-_, >= ves 
NodeTotals {Node} ; 

NodeTotals {N cde2} ; 
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NodeTotals {Node3} ; 
qdisplayn {} : 
DisplayLine{[ "Job", "Time" ]} ; 
Pes meay Lanesweu——=———-—-= =e codes 
JobTotals{Nil, 0}; 
a(t); 
3; 
if *NodeTotals(a, node), *BusyTime({node, t), 
*QOLength(node, n) -> { 
DisplayLine{; node, t, ni}; 
a(node) ; 
}; 
if *JobTotals(a, 1, nj), 
Horie limei yj, tl), *ExitTime (j, t2) -> 
Nouwmota Esta rCONS jy. t2z-tl)j, 1), n*t2-t 1) 


ese at *JobTotals(a, 1, n) -> { 
JobTotalsAux {1}; 
displayn {3} ; 
Moaplavyrmame | Total", n }} ; 
a(JobTotals) ; 
}; 

if *JotTotalsAux(a, Nil) -> 
a(JobTotalsA ux) 


else if *JobTotalsAux(a, 1) -> { 
Dispraylaine f{farst; 1 ]}3 
JobTotalsAux (a, rest[1}); 
oa 


feeeDisplayLine(a, Nil) -> f{ 
displayn {}; 
a(DispiayLine); 


13.5 


j 


else if *DisplayLine (a, 1) -> { 


display {" as 
display {first ie 
DisplayLine({a, rest[{1j)= 
3 
! 
! the events -- Start, Arrive, Depart 


o—8 


If PHStart ta, tle ey ee 
CalcNextArr{t, Nodel}; 
CalcNextArr{t, Node2}; 
a(t); 

} 


if *Arrive(a, “tt, node, “iiendon") —> a: 
NewArrival{t, node, NewJob {}}; 
a (t) 
} 


else if *Arrive (dad, t, Out, 900) —— e 
Ex etame (ont): 
a (t) 
} 


else if *Arrive(a, t, node, job) @= a 
Service{t, node, job}; 
a(t) ; 
a 


if *NewArrival{a, t, node, job) <-> { 
StartTime(job, t); 
Ca lenextaArr{t ,enoce):; 
JobServiceT(job, GenServT {Rnd {}}); 


Service {t, node, job}; 
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ane) ; 
33 


[fe ceorviceia, t, Node, job), *iInservice(node, "--") -> { 


else if 


InService (node, job) ; 
CalcDeparture{t, node, job}; 
a (t) 

} 


rSonvace (ay ty, NMOGe, JO) => £ 
Eng {node, job}; 

a(t); 

33 


if *Depart(a, t, node, job), 


Q(node, Nil), *InService (node, job) -> 


else if 


TnService(node, "--"), 
a (t) 


*Depart (a, t, node, job), 

*Q (node, 1), *InService (node, job) -> 
{ 

Q(node, rest{1]); 

InService(node, "--"); 

Semvyice:t, mouae, first[1}}; 

a(t) ; 

}; 


iee*~CalcNextaArr(a,t,ncde), JobCcunt (n1i,n2,max), ni>=max -> 


a(t) 


else if *CaicNextArr (a,t,node), *JobCount(n1,n2,max) -> 


{ 


Jopeount (Nii, n2; max) ; 
Event (t+GenArrT {node,End {}}, Arrive, node, "NewJob!) ; 
a(t); 
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if *CaicDeparture(a,t,node, job) , JobServiceT (job,servi jee 


{ 


Event (t+servT,Depart,node, job); 


Event(ttservT,Arrive,GenRkoute {node, Rnd {}}, job) ; 


a(t); 
3 


1i *Eng (a, node, job), *O(node7 = 
Q(node, appendjl, {job}"), 


a (node) ; 
1f *NewJob(a), *JobCount(n1l, n2, max) -> 


JobCount (hp iy 224, mace, 
a("dob"+41nt StrlaZztieyee: 


Sod 


parameter generators 


q GenServT -- Generate a service time for a message 
! GenArrT -- Generate an interarrival time for a job 
! GenRoute -- Generate the next node for a departure 


tus 


if *GenServi(a, x), ServiceTine (ti, 3. ee 
(>= 1 1S i <eee e 
a(t); 


if *GenArrT (a, node, x), ArriInterval (node, t, il, 


(xX SS 21): Ax <= a 
a); 
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12), 


if *GenRoute(a, node, x), PossilkleRoutes(node, n2, il, i2), 
(X Set 6 (xX <= a2) -> 
a(n2); 


¢—— 


The random number generator .... 


The Rnd procedure takes the first number from the 


oom 


list of random numbers in WorkList. 


! Seed makes the WorkList the portion of the 


Cus 


RndList with the ith menbec as the first member. 


If the list of random numbers is exhausted, 


the WorkList is set back to the beginning of 


oe, 


the original list of random numbers. 


if *Seed(a, n), RndList(1l), *WorkList(wl) -> 
MOomkbist (ith[ i, nj), 


aati 


if *Rnd(a), *WorkList (Nil), Rndlist(1) -> 
WorkList(rest[1]), 
a(first[1)]) 


else if *Rnd({a), *WorkList(l) -> 
Worklist(rest[1]), 
eueie St fv }) = 


>) . 
! Activate the rules... 


activate {SimRules}. 


SS 


DR a aK aK ke aK 2 2 2 aK 2a ea a ae i a ee oo ok oe Ke ak oc ok oe oo ok ok a KK ok K 
! 
! Towers of Hanoi ! 
1 t 


Toe A KK KK KK KK ORK KOK KK KK KK KK KK 


! define the relations 


definef{root, "Hanoi", newrel {}}. 


define{root, "HanoiAux", newrel {f}}. 


! The cules 
define{root, "Hanork ules’, 
<< 


1£ *Hanol(a, n) -> 


HanoidAux (a, np, VA, NC Sa eae. 


if *HanolAux(a, 1, f£EOm, to, aus) == 7a 
display{"Move disk 1 from peg "}; 
display {fron}; 
display {" Sto cegqu: 
displa yn {to} ; 
a("") 


j 


else if *HanolAux(a, Db, £ron, tc, aux) = 
HanorvAux {n-—1, Erom, aux, ato, 
dispiay{"Move disk "}; 
display {n}; 
display{i" £2en peg “iz 
display {fron}; 
display{" to peg "}; 
displayn {to} ; 
HanOLAUX {l—-1, aux, to,menone 
an 
} 

ae 
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activate {Hanoikules}. 


displayn{"Towers of Hanoi : Usage : Hanoif{n}"}. 


1K kk KR tO ok ok kkk ok doko kk ak kak kkk tok dok kok ok kok kok dk 
! The Sieve of Eratosthenes : 
! ! 
'For a description of this algorithm, see ! 
!''Eratosthenes revisited : Once More through the Sieve',! 
ey Jim and Gary Gilbreath, Byte, Jan 83, p 283. ! 
: : 


UK KOK KK KK KK KK KK KK KK KK KOK KK KK KK EK KK ok KK oe OK KKK KI 


define{root, "Sieve", newrel {}}. 
define{root, "SieveAux", newrel {ff}. 
define{root, "Iota", newrel {}}. 


define{root, "PurgeMultiples", newrel {}}. 
: the rules 


define{root, "Sievekules", 


<< 


if *Sieve(a, n) -> systen("date"), 


SieveAux {a, 0, n-1, Iota{0, n-1, newrel {}}); 


meer lota(a, ni, n2, r), ni > n2 -> 


a {r) 


else if *lota(a, ni, n2, ©) -> 
ive} 


Hotala, nl, n2-1,.r) ; 


mime SoacveAux({a, ni, n2, r), nl >n2 -> 


a ("OK") 


Smoe it *SieveAux(a, nl, n2, ©), E(n1) -> { 


20 1 


display{"Prime : "}; 
display {2*na +3. 
PurgeMultiples{2*nl + 3, 3*#nl +s eu ee 
SieveAux(a, ni+t1l, n2, T); 
} 
else if *SieveAux(a, ni, n2, ©) -> 
SievedAux (a, nit, nZ7 er); 
if *PurgeMultiples (a, prime, sut, nn, ©) Sute ee 
a (Ir) 
else if *PurgeMultiples(a, prime, sum, n, r), *rc (sum) -> 
PurgeMultiples(a, prime, prime+sum, n, I) 
else 1f£ *PurgeMultiples(a, prime, sum, n, ©) -> 


PurgeMultiples(a, prime, prime+sum, n, I); 
ye hie 
activate {Sievekules}. 


displayn{"The sieve is loaded : Usage : Sieve{n}"}. 


Yok 2K ok aK aK ok oo a oe ok ok ok a ke ak ok a oo ck ok ak ok oak ok obo ok ok ok ok oe oe ok ok ok a ok ok ok ok ok ok ok a a ok ok kok ook 


: 


! Rules and asscciated definitions for a universal 


} 


! 


! interpreter/pretty printer for a small Language of! 


! arithmetic expressions. 


! 


L 


: 


VR RK OK KK KK I KK KK IK OK Ke KK i AK KK a a kK Ko Kk ok ak aK KKK eK KK aK ok kK KT 


! definitions 


define{root, "Small", newrel {}}; 
define{root, "Wait", newrel {}}; 
define{root, "Eval", newrel {}};3 


define{root, "Vaiue", newrel {}}; 


ZZ 


define{root, "Appl", newrel {}}; 
define{root, "Op", newrel 3}; 
define{root, "Left", newrel {}}; 
definef{root, "Right", newrel 9}; 
define{root, "Con", newrel {}};3 
definefroot, "Litval", newrel {}}; 
define{root, "Meaning", newrel {}}; 


define{root, "Template", newrel §}; 


! schne objects 

define{root, "Ni", newobj {}}; 
definef{root, "N2", newobj{}}; 
definef{root, "N3", newobj ff}; 
define{root, "NG", newobs ff}; 


definef{root, "N5", newobj {}}. 


; PURE Oils 

mip 2a(/ x]: x; 

PieouUn, X,Y} : xX + Y¥; 

meer Locuct[ x,y] : x * y; 

Pupsumix,yj: "(" +x + ™ + 1 + y + 1). 


Pmuoriega x,y jes 8 ("ot ey + MN x Wt y + N)N, 


! initialize the database 


Appl (N1) ; 
Sox, Nt); 
Left (N2, N11); 
Right (N3, N1); 


Appl (N2) ; 
Op("+", N2); 
Left (N4, N2); 
Right (N5, N2); 


Con (N3) ; 
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ary alee 
Con (N4); 
Last Vv amite 
Con (N5) ; 


po ye 


N4) ; 


at vant Wo) 


Meaning ( 


Meaning (Product, 


Meaning ( 


Template(upSun, 
Template(upProd, 


Gnt- Stress ee 


Template 


: 


define{root, 


<< 


Sui, ey : 


Id, "lit") ; 


the Rules 


YE Priver. mile 


ety. 


ey i 


" x) : 


"SmaliRules", 


if *Small (node) 


=2 


Eval (Meaning, 


Eval (Template, 


Wait (node) ; 


ir *Value (Meaning, 


*Value(Template, 


*Wait (node) 


=> 


displayn (x), 
displayn (y) ; 


! Inheritance rules 


! Leaf node 
shale 


*Eval(ciass, 


€) s 


Ye 
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node) , 


node), 


nede) , 


node), 


Con (e), 

Litval(v,e), 

Class (f,. "lac 
-> 


Value(class, i[v], e); 


! Appl node 


ae 

*Eval(class, €), 
Appl(e), 

Left(x,e), Right (y,e) 


a 
Eval(class, x), 
BVeliclass;, Yis3 
! Synthesis rule 
ae 
*Value(class, u,X), 
*Value (class, v,yY), 
Appl(e), 
Op(n,e), 
Left (x,e), 
Right (y,e), 
Class(f, n) 
ae 


Value(class, tj u,v], e) 
Pe} . 
! activate the rules 


activatej SmallRules }. 


displayn{"Small interpreter loaded ;: u Small(N1)"3. 
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